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Abstract 


This document specifies the Group Secure Association Key Management 
Protocol (GSAKMP). The GSAKMP provides a security framework for 
creating and managing cryptographic groups on a network. It provides 
mechanisms to disseminate group policy and authenticate users, rules 
to perform access control decisions during group establishment and 
recovery, capabilities to recover from the compromise of group 
members, delegation of group security functions, and capabilities to 
destroy the group. It also generates group keys. 
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1. Introduction 


GSAKMP provides policy distribution, policy enforcement, key 
distribution, and key management for cryptographic groups. 
Cryptographic groups all share a common key (or set of keys) for data 
processing. These keys all support a system-level security policy so 
that the cryptographic group can be trusted to perform security- 
relevant services. 


The ability of a group of entities to perform security services 
requires that a Group Secure Association (GSA) be established. A GSA 
ensures that there is a common "group-level" definition of security 
policy and enforcement of that policy. The distribution of 
cryptographic keys is a mechanism utilizing the group-level policy 
enforcements. 


1.1. GSAKMP Overview 


Protecting group information requires the definition of a security 
policy and the enforcement of that policy by all participating 
parties. Controlling dissemination of cryptographic key is the 
primary mechanism to enforce the access control policy. It is the 
primary purpose of GSAKMP to generate and disseminate a group key in 
a secure fashion. 


GSAKMP separates group security management functions and 
responsibilities into three major roles:1) Group Owner, 2) Group 
Controller Key Server, and 3) Group Member. The Group Owner is 
responsible for creating the security policy rules for a group and 
expressing these in the policy token. The Group Controller Key 
Server (GC/KS) is responsible for creating and maintaining the keys 
and enforcing the group policy by granting access to potential Group 
Members (GMs) in accordance with the policy token. To enforce a 
group’s policy, the potential Group Members need to have knowledge of 
the access control policy for the group, an unambiguous 
identification of any party downloading keys to them, and verifiable 
chains of authority for key download. In other words, the Group 
Members need to know who potentially will be in the group and to 
verify that the key disseminator is authorized to act in that 
capacity. 


In order to establish a Group Secure Association (GSA) to support 
these activities, the identity of each party in the process MUST be 
unambiguously asserted and authenticated. It MUST also be verified 
that each party is authorized, as defined by the policy token, to 
function in his role in the protocol (e.g., GM or GC/KS). 
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The security features of the establishment protocol for the GSA 
include 


- Group policy identification 

- Group policy dissemination 

- GM to GC/KS SA establishment to protect data 
- Access control checking 


GSAKMP provides mechanisms for cryptographic group creation and 
management. Other protocols may be used in conjunction with GSAKMP 
to allow various applications to create functional groups according 
to their application-specific requirements. For example, ina 
small-scale video conference, the organizer might use a session 
invitation protocol like SIP [RFC3261] to transmit information about 
the time of the conference, the address of the session, and the 
formats to be used. For a large-scale video transmission, the 
organizer might use a multicast announcement protocol like SAP 
[RFC2974]. 


This document describes a useful default set of security algorithms 
and configurations, Security Suite 1. This suite allows an entire 
set of algorithms and settings to be described to prospective group 
members in a concise manner. Other security suites MAY be defined as 
needed and MAY be disseminated during the out-of-band announcement of 
a group. 


Distributed architectures support large-scale cryptographic groups. 
Secure distributed architectures require authorized delegation of GSA 
actions to network resources. The fully specified policy token is 
the mechanism to facilitate this authorization. Transmission of this 
policy token to all joining GMs allows GSAKMP to securely support 
distributed architectures and multiple data sources. 


Many-to-many group communications require multiple data sources. 
Multiple data sources are supported because the inclusion of a policy 
token and policy payloads allow group members to review the group 
access control and authorization parameters. This member review 
process gives each member (each potential source of data) the ability 
to determine if the group provides adequate protection for member 
data. 
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1.2. Document Organization 


The remainder of this document is organized as follows:Section 2 
presents the terminology and concepts used to present the 
requirements of this protocol. Section 3 outlines the security 
considerations with respect to GSAKMP. Section 4 defines the 
architecture of GSAKMP. Section 5 describes the group management 
life cycle. Section 6 describes the Security Suite Definition. 
Section 7 presents the message types and formats used during each 
phase of the life cycle. Section 8 defines the state diagram for the 
protocol. 


2. Terminology 
The following terminology is used throughout this document. 


Requirements Terminology: Keywords "MUST", "MUST NOT", "REQUIRED", 
"SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to 
be interpreted as described in [RFC2119]. 


Certificate: A data structure used to verifiably bind an identity to 
a cryptographic key (e.g., X.509v3). 


Compromise Recovery: The act of recovering a secure operating state 
after detecting that a group member cannot be trusted. This can 
be accomplished by rekey. 


Cryptographic Group: A set of entities sharing or desiring to share a 
GSA. 


Group Controller Key Server (GC/KS): A group member with authority to 
perform critical protocol actions including creating and 
distributing keys and building and maintaining the rekey 
structures. As the group evolves, it MAY become desirable to have 
multiple controllers perform these functions. 


Group Member (GM): A Group Member is any entity with access to the 
group keys. Regardless of how a member becomes a part of the 
group or how the group is structured, GMs will perform the 
following actions: 


Authenticate and validate the identities and the authorizations 
of entities performing security-relevant actions 


Accept group keys from the GC/KS 


- Request group keys from the GC/KS 
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- Enforce the cooperative group policies as stated in the group 
policy token 


- Perform peer review of key management actions 
- Manage local key 


Group Owner (GO): A Group Owner is the entity authorized for 
generating and modifying an authenticatable policy token for the 
group, and notifying the GC/KS to start the group. 


Group Policy: The Group Policy completely describes the protection 
mechanisms and security-relevant behaviors of the group. This 
policy MUST be commonly understood and enforced by the group for 
coherent secure operations. 


Group Secure Association (GSA): A GSA is a logical association of 
users or hosts that share cryptographic key(s). This group may be 
established to support associations between applications or 
communication protocols. 


Group Traffic Protection Key (GTPK): The key or keys created for 
protecting the group data. 


Key Datum: A single key and its associated attributes for its usage. 


Key Encryption Key (KEK): Key used in an encryption mechanism for 
wrapping another key. 


Key Handle: The identifier of a particular instance or version of a 
key. 


Key ID: The identifier for a key that MUST stay static throughout the 
life cycle of this key. 


Key Package: Type/Length/Data format containing a Key Datum. 


Logical Key Hierarchy (LKH) Array: The group of keys created to 
facilitate the LKH compromise recovery methodology. 


Policy Token (PT): The policy token is a data structure used to 
disseminate group policy and the mechanisms to enforce it. The 
policy token is issued and signed by an authorized Group Owner. 
Each member of the group MUST verify the token, meet the group 
join policy, and enforce the policy of the group (e.g., encrypt 
application data with a specific algorithm). The group policy 
token will contain a variety of information including: 
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-= GSAKMP protocol version 
- Key creation method 
- Key dissemination policy 
- Access control policy 
- Group authorization policy 
- Compromise recovery policy 
- Data protection mechanisms 
Rekey: The act of changing keys within a group as defined by policy. 


Rekey Array: The construct that contains all the rekey information 
for a particular member. 


Rekey Key: The KEK used to encrypt keys for a subset of the group. 
Subordinate Group Controller Key Server (S-GC/KS): Any group member 


having the appropriate processing and trust characteristics, as 
defined in the group policy, that has the potential to act asa 


S-GC/KS. This will allow the group processing and communication 
requirements to be distributed equitably throughout the network 
(e.g., distribute group key). The optional use of GSAKMP with 


Subordinate Group Controller Key Servers will be documented in a 
separate paper. 


Wrapping KeyID: The Key ID of the key used to wrap a Key Package. 


Wrapping Key Handle: The key handle of the key used to wrap the Key 
Package. 
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3. Security Considerations 


In addition to the specification of GSAKMP itself, the security of 
an implemented GSAKMP system is affected by supporting factors. 
These are discussed here. 


3.1. Security Assumptions 


The following assumptions are made as the basis for the security 
discussion: 


1. GSAKMP assumes its supporting platform can provide the process 
and data separation services at the appropriate assurance level 
to support its groups. 


2. The key generation function of the cryptographic engine will only 
generate strong keys. 


3. The security of this protocol is critically dependent on the 
randomness of the randomly chosen parameters. These should be 
generated by a strong random or properly seeded pseudo-random 
source [RFC4086]. 


4. The security of a group can be affected by the accuracy of the 
system clock. Therefore, GSAKMP assumes that the system clock is 
close to correct time. If a GSAKMP host relies on a network time 
service to set its local clock, then that protocol must be secure 
against attackers. The maximum allowable clock skew across the 
group membership is policy configurable, with a default of 5 
minutes. 


5. As described in the message processing section, the use of the 
nonce value used for freshness along with a signature is the 
mechanism used to foil replay attacks. In any use of nonces, a 
core requirement is unpredictability of the nonce, from an 
attacker’s viewpoint. The utility of the nonce relies on the 
inability of an attacker either to reuse old nonces or to predict 
the nonce value. 


6. GSAKMP does not provide identity protection. 


7. The group’s multicast routing infrastructure is not secured by 
GSAKMP, and therefore it may be possible to create a multicast 
flooding denial of service attack using the multicast 
application’s data stream. Either an insider (i.e., a rogue GM) 
or a non-member could direct the multicast routers to spray data 
at a victim system. 
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8. The compromise of a S-GC/KS forces the re-registration of all GMs 
under its control. The GM recognizes this situation by finding 
the S-GC/KS's certificate on a CRL as supplied by a service such 
as LDAP. 

9. The compromise of the GO forces termination of the group. The GM 


recognizes this situation by finding the GO’s certificate on a 
Certificate Revocation List (CRL) as supplied by a service such 
as LDAP. 


3.2. Related Protocols 


GSAKMP derives from two (2) existing protocols: ISAKMP [RFC2408] and 
FIPS Pub 196 [FIPS196]. In accordance with Security Suite 1, GSAKMP 
implementations MUST support the use of Diffie-Hellman key exchange 
[DH77] for two-party key creation and MAY use Logical Key Hierarchy 
(LKH) [RFC2627] for rekey capability. The GSAKMP design was also 
influenced by the following protocols: [HHMCDO1], [RFC2093], 
[RFC2094], [BMS], and [RFC2412]. 


3.2.1. ISAKMP 


ISAKMP provides a flexible structure of chained payloads in support 
of authenticated key exchange and security association management for 


pairwise communications. GSAKMP builds upon these features to 
provide policy enforcement features in support of diverse group 
communications. 


3.2.2. FIPS Pub 196 


FIPS Pub 196 provides a mutual authentication protocol. 


3.2.3. LKH 


When group policy dictates that a recovery of the group security is 
necessary after the discovery of the compromise of a GM, then GSAKMP 
relies upon a rekey capability (i.e., LKH) to enable group recovery 
after a compromise [RFC2627]. This is optional since in many 
instances it may be better to destroy the compromised group and 
rebuild a secure group. 
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3.2.4. Diffie-Hellman 


A Group may rely upon two-party key creation mechanisms, i.e., 
Diffie-Hellman, to protect sensitive data during download. 


The information in this section borrows heavily from [IKEv2], as this 
protocol has already worked through similar issues and GSAKMP is 
using the same security considerations for its purposes. This 
section will contain paraphrased sections of [IKEv2] modified for 
GSAKMP as appropriate. 


The strength of a key derived from a Diffie-Hellman exchange using 
specific p and g values depends on the inherent strength of the 
values, the size of the exponent used, and the entropy provided by 
the random number generator used. A strong random number generator 
combined with the recommendations from [RFC3526] on Diffie-Hellman 
exponent size is recommended as sufficient. An implementation should 
make note of this conservative estimate when establishing policy and 
negotiating security parameters. 


Note that these limitations are on the Diffie-Hellman values 
themselves. There is nothing in GSAKMP that prohibits using stronger 
values, nor is there anything that will dilute the strength obtained 
from stronger values. In fact, the extensible framework of GSAKMP 
encourages the definition of more Security Suites. 


It is assumed that the Diffie-Hellman exponents in this exchange are 
erased from memory after use. In particular, these exponents MUST 
NOT be derived from long-lived secrets such as the seed to a pseudo- 
random generator that is not erased after use. 


3.3. Denial of Service (DoS) Attack 


This GSAKMP specification addresses the mitigation for a distributed 
IP spoofing attack (a subset of possible DoS attacks) in Section 
5.2.2, "Cookies: Group Establishment with Denial of Service 
Protection". 


3.4. Rekey Availability 


In addition to GSAKMP’s capability to do rekey operations, GSAKMP 
MUST also have the capability to make this rekey information highly 
available to GMs. The necessity of GMs receiving rekey messages 
requires the use of methods to increase the likelihood of receipt of 
rekey messages. These methods MAY include multiple transmissions of 
the rekey message, posting of the rekey message on a bulletin board, 
etc. Compliant GSAKMP implementations supporting the optional rekey 
capability MUST support retransmission of rekey messages. 
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3.5. Proof of Trust Hierarchy 


As defined by [HCM], security group policy MUST be defined in a 
verifiable manner. GSAKMP anchors its trust in the creator of the 
group, the GO. 


The policy token explicitly defines all the parameters that create a 
secure verifiable infrastructure. The GSAKMP Policy Token is issued 
and signed by the GO. The GC/KS will verify it and grant access to 
GMs only if they meet the rules of the policy token. The new GMs 
will accept access only if 1) the token verifies, 2) the GC/KS is an 
authorized disseminator, and 3) the group mechanisms are acceptable 
for protecting the GMs data. 


4. Architecture 
This architecture presents a trust model for GSAKMP and a concept of 
operations for establishing a trusted distributed infrastructure for 
group key and policy distribution. 
GSAKMP conforms to the IETF MSEC architectural concepts as specified 
in the MSEC Architecture document [RFC3740]. GSAKMP uses the MSEC 
components to create a trust model for operations that implement the 
security principles of mutual suspicion and trusted policy creation 
authorities. 

4.1. Trust Model 

4.1.1. Components 
The trust model contains four key components: 
- Group Owner (GO), 
- Group Controller Key Server (GC/KS), 
- Subordinate GC/KS (S-GC/KS), and 
- Group Member (GM). 
The goal of the GSAKMP trust model is to derive trust from a common 
trusted policy creation authority for a group. All security-relevant 
decisions and actions implemented by GSAKMP are based on information 
that ultimately is traceable to and verified by the trusted policy 
creation authority. There are two trusted policy creation 


authorities for GSAKMP: the GO (policy creation authority) and the 
PKI root that allows us to verify the GO. 
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4.1.2. GO 


The GO is the policy creation authority for the group. The GO has a 
well-defined identity that is relevant to the group. That identity 
can be of a person or of a group-trusted component. All potential 
entities in the group have to recognize the GO as the individual with 
authority to specify policy for the group. 


The policy reflects the protection requirements of the data in a 
group. Ultimately, the data and the application environment drives 
the security policy for the group. 


The GO has to determine the security rules and mechanisms that are 
appropriate for the data being protected by the group keys. All this 
information is captured in a policy token (PT). The GO creates the 
PT and signs it. 


4.1.3. GC/KS 


The GC/KS is authorized to perform several functions: key creation, 
key distribution, rekey, and group membership management. 


As the key creation authority, the GC/KS will create the set of keys 
for the group. These keys include the Group Traffic Protection Keys 
(GTPKs) and first-tier rekey keys. There may be second-tier rekey 
trees if a distributed rekey management structure is required for the 
group. 


As the key distribution (registration) authority, it has to notify 
the group of its location for registration services. The GC/KS will 
have to enforce key access control as part of the key distribution 
and registration processes. 


As the group rekey authority, it performs rekey in order to change 
the group’s GIPK. Change of the GTPK limits the exposure of data 
encrypted with any single GTPK. 


Finally, as the group membership management authority, the GC/KS can 
manage the group membership (registration, eviction, de-registration, 
etc.). This may be done in part by using a key tree approach, such 
as Logical Key Hierarchies (LKH), as an optional approach. 
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4.1.4. Subordinate GC/KS 


A subordinate GC/KS is used to distribute the GC/KS functionality 
across multiple entities. The S-GC/KS will have all the authorities 
of the GC/KS except one: it will not create the GTPK. It is assumed 
here that the group will transmit data with a single GTPK at any one 
time. This GIPK comes from the GC/KS. 


Note that relative to the GC/KS, the S-GC/KS is responsible for an 
additional security check: the S-GC/KS must register as a member with 
the GC/KS, and during that process it has to verify the authority of 
the GC/KS. 


4.1.5. GM 


The GM has two jobs: to make sure all security-relevant actions are 
authorized and to use the group keys properly. During the 
registration process, the GM will verify that the PT is signed by a 
recognized GO. In addition, it will verify that the GC/KS or S-GC/KS 
engaged in the registration process is authorized, as specified in 
the PT. If rekey and new PTs are distributed to the group, the GM 
will verify that they are proper and all actions are authorized. 


The GM is granted access to group data through receipt of the group 
keys This carries along with it a responsibility to protect the key 
from unauthorized disclosure. 


GSAKMP does not offer any enforcement mechanisms to control which GMs 
are multicast speakers at a given moment. This policy and its 
enforcement depend on the multicast application and its protocols. 
However, GSAKMP does allow a group to have one of three Group 
Security Association multicast speaker configurations: 


- There is a single GM authorized to be the group’s speaker. There 
is one multicast application SA allocated by the GO in support of 
that speaker. The PT initializes this multicast application SA 
and identifies the GM that has been authorized to be speaker. All 
GMs share a single TPK with that GM speaker. Sequence number 
checking for anti-replay protection is feasible and enabled by 
default. This is the default group configuration. GSAKMP 
implementations MUST support this configuration. 


- The GO authorizes all of the GMs to be group speakers. The GO 
allocates one multicast application SA in support of these 
speakers. The PT initializes this multicast application SA and 
indicates that any GM can be a speaker. All of the GMs share a 
single GTPK and other SA state information. Consequently, some SA 
security features such as sequence number checking for anti-replay 
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4. 


1. 


6. 


protection cannot be supported by this configuration. GSAKMP 
implementations MUST support this group configuration. 


The GO authorizes a subset of the GMs to be group speakers (which 


may be the subset composed of all GMs). The GO allocates a 
distinct multicast application SA for each of these speakers. The 
PT identifies the authorized speakers and initializes each of 
their multicast application Security Associations. The speakers 


still share a common TPK across their SA, but each speaker has a 
separate SA state information instance at every peer GM. 
Consequently, this configuration supports SA security features, 
such as sequence number checking for anti-replay protection, or 
source authentication mechanisms that require per-speaker state at 
the receiver. The drawback of this configuration is that it does 
not scale to a large number of speakers. GSAKMP implementations 
MAY support this group configuration. 


Assumptions 


The assumptions for this trust model are that: 


the GCKS is never compromised, 
the GO is never compromised, 
the PKI, subject to certificate validation, is trustworthy, 


The GO is capable of creating a security policy to meet the 
demands of the group, 


the compromises of a group member will be detectable and reported 
to the GO in a trusted manner, 


the subsequent recovery from a compromise will deny inappropriate 
access to protected data to the compromised member, 


no security-relevant actions depend on a precise network time, 
there are confidentiality, integrity, multicast source 
authentication, and anti-replay protection mechanisms for all 


GSAKMP control messages. 


Rule-Based Security Policy 


The trust model for GSAKMP revolves around the definition and 
enforcement of the security policy. In fact, the use of the key is 
only relevant, in a security sense, if it represents the successful 
enforcement of the group security policy. 
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Group operations lend themselves to rule-based security policy. The 
need for distribution of data to many endpoints often leads to the 
defining of those authorized endpoints based on rules. For example, 
all IETF attendees at a given conference could be defined as a single 
group. 


If the security policy rules are to be relevant, they must be coupled 
with validation mechanisms. The core principle here is that the 
level of trust one can afford a security policy is exactly equal to 
the level of trust one has in the validation mechanism used to prove 
that policy. For example, if all IETF attendees are allowed in, then 
they could register their identity from their certificate upon 
check-in to the meetings. That certificate is issued by a trusted 
policy creation authority (PKI root) that is authorized to identify 
someone as an IETF attendee. The GO could make admittance rules to 
the IETF group based on the identity certificates issued from trusted 
PKIs. 


In GSAKMP, every security policy rule is coupled with an explicit 
validation mechanism. For interoperability considerations, GSAKMP 
requires that its supporting PKI implementations MUST be compliant to 
RFC 3280. 


If a GM’s public key certificate is revoked, then the entity that 
issues that revocation SHOULD signal the GO, so that the GO can expel 
that GM. The method that signals this event to the GO is not 
standardized by this specification. 


A direct mapping of rule to validation mechanism allows the use of 
multiple rules and PKIs to create groups. This allows a GO to define 
a group security policy that spans multiple PKI domains, each with 
its own Certificate Authority public key certificate. 


4.2.1. Access Control 


The access control policy for the group keys is equivalent to the 
access control policy for the multicast application data the keys are 
protecting. 


In a group, each data source is responsible for ensuring that the 
access to the source’s data is appropriate. This implies that every 
data source should have knowledge of the access control policy for 
the group keys. 


In the general case, GSAKMP offers a suite of security services to 
its applications and does not prescribe how they use those services. 
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GSAKMP supports the creation of GSAs with multiple data sources. It 
also supports architectures where the GC/KS is not itself a data 


source. In the multiple data source architectures GSAKMP requires 
that the access control policy is precisely defined and distributed 
to each data source. The reference for this data structure is the 


GSAKMP Policy Token [RFC4534]. 
4.2.2. Authorizations for Security-Relevant Actions 


A critical aspect of the GSAKMP trust model is the authorization of 
security-relevant actions. These include download of group key, 
rekey, and PT creation and updates. These actions could be used to 
disrupt the secure group, and all entities in the group must verify 
that they were instigated by authorized entities within the group. 


4.3. Distributed Operation 


Scalability is a core feature of GSAKMP. GSAKMP’s approach to 
scalable operations is the establishment of S-GC/KSes. This allows 
the GSAKMP systems to distribute the workload of setting up and 
managing very large groups. 


Another aspect of distributed S-GC/KS operations is the enabling of 
local management authorities. In very large groups, subordinate 
enclaves may be best suited to provide local management of the 
enclaves’ group membership, due to a direct knowledge of the group 
members. 


One of the critical issues involved with distributed operation is the 
discovery of the security infrastructure location and security suite. 
Many group applications that have dynamic interactions must "find" 
each other to operate. The discovery of the security infrastructure 
is just another piece of information that has to be known by the 
group in order to operate securely. 

There are several methods for infrastructure discovery: 

- Announcements 

- Anycast 

- Rendezvous points / Registration 

One method for distributing the security infrastructure location is 


to use announcements. The SAP is commonly used to announce the 
existence of a new multicast application or service. If an 
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application uses SAP [RFC2974] to announce the existence of a service 
on a multicast channel, that service could be extended to include the 
security infrastructure location for a particular group. 


Announcements can also be used by GSAKMP in one of two modes: 
expanding ring searches (ERSes) of security infrastructure and ERSes 
for infrastructure discovery. In either case, the GSAKMP would use a 
multicast broadcast that would slowly increase in its range by 
incremental multicast hops. The multicast source controls the 
packet’s multicast range by explicitly setting its Time To Live 
count. 


An expanding ring announcement operates by the GC/KS announcing its 
existence for a particular group. The number of hops this 
announcement would travel would be a locally configured number. The 
GMs would listen on a well-known multicast address for GC/KSes that 
provide service for groups of interest. If multiple GC/KSes are 
found that provide service, then the GM would pick the closest one 
(in terms of multicast hops). The GM would then send a GSAKMP 
Request to Join message (RTJ) to the announced GC/KS. If the 
announcement is found to be spurious, then that is reported to the 
appropriate management authorities. The ERA concept is slightly 
different from SAP in that it could occur over the data channel 
multicast address, instead of a special multicast address dedicated 
for the SAP service. 


An expanding ring search operates in the reverse order of the ERA. 

In this case, the GM is the announcing entity. The (S-)GC/KSes 
listen for the requests for service, specifically the RTJ. The 
(S-)GC/KS responds to the RTJ. If the GM receives more than one 
response, it would either ignore the responses or send NACKs based on 
local configuration. 


Anycast is a service that is very similar to ERS. It also can be 
used to provide connection to the security infrastructure. In this 
case, the GM would send the RTJ to a well-known service request 
address. This anycast service would route the RTJ to an appropriate 
GC/KS. The anycast service would have security infrastructure and 
network connectivity knowledge to facilitate this connection. 


Registration points can be used to distribute many group-relevant 
data, including security infrastructure. Many group applications 
rely on well-known registration points to advertise the availability 
of groups. There is no reason that GSAKMP could not use the same 
approach for advertising the existence and location of the security 
infrastructure. This is a simple process if the application being 
supported already supports registration. The GSAKMP infrastructure 
can always provide a registration site if the existence of this 
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security infrastructure discovery hub is needed. The registration of 
S-GC/KSes at this site could be an efficient way to allow GM 
registration. 


GSAKMP infrastructure discovery can use whatever mechanism suits a 
particular multicast application's requirements, including mechanisms 
that have not been discussed by this architecture. However, GSAKMP 
infrastructure discovery is not standardized by this version of the 
GSAKMP specification. 


4.4. Concept of Operation 


This concept of operation shows how the different roles in GSAKMP 
interact to set up a secure group. This particular concept of 
operation focuses on a secure group that utilizes the distributed key 
dissemination services of the S-GC/KS. 


4.4.1. Assumptions 


The most basic assumption here is that there is one or more 
trustworthy PKIs for the group. That trusted PKI will be used to 
create and verify security policy rules. 


There is a GO that all GMs recognize as having group policy creation 
authority. All GM must be securely pre-configured to know the GO 
public key. 


All GMs have access to the GO PKI information, both the trusted 
anchor public keys and the certificate path validation rules. 


There is sufficient connectivity between the GSAKMP entities. 


- The registration SA requires that GM can connect to the GC/KS or 
S-GC/KS using either TCP or UDP. 


- The Rekey SA requires that the data-layer multicast communication 
service be available. This can be multicast IP, overlay networks 


using TCP, or NAT tunnels. 


-= GSAKMP can support many different data-layer secure applications, 
each with unique connectivity requirements. 


4.4.2. Creation of a Policy Token 
The GO creates and signs the policy token for a group. The policy 


token contains the rules for access control and authorizations for a 
particular group. 
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The PT consists of the following information: 


= Identification: This allows an unambiguous identification of the 
PT and the group. 


- Access Control Rules: These rules specify who can have access to 
the group keys. 


- Authorization Rules: These rules specify who can be a S-GC/KS. 


- Mechanisms: These rules specify the security mechanisms that will 
be used by the group. This is necessary to ensure there is no 
weak link in the group security profile. For example, for IPsec, 
this could include SPD/SAD configuration data. 


- Source authentication of the PT to the GO: The PT is a CMS signed 
object, and this allows all GMs to verify the PT. 


4.4.3. Creation of a Group 


The PT is sent to a potential GC/KS. This can occur in several ways, 
and the method of transmittal is outside the scope of GSAKMP. The 
potential GC/KS will verify the GO signature on the PT to ensure that 
it comes from a trusted GO. Next, the GC/KS will verify that it is 
authorized to become the GC/KS, based on the authorization rules in 
the PT. Assuming that the GC/KS trusts the PT, is authorized to be a 
GC/KS, and is locally configured to become a GC/KS for a given group 
and the GO, then the GC/KS will create the keys necessary to start 
the group. The GC/KS will take whatever action is necessary (if any) 
to advertise its ability to distribute key for the group. The GC/KS 
will then listen for RTJs. 


The PT has a sequence number. Every time a PT is distributed to the 
group, the group members verify that the sequence number on the PT is 
increasing. The PT lifetime is not limited to a particular time 
interval, other than by the lifetimes imposed by some of its 
attributes (e.g., signature key lifetime). The current PT sequence 
number is downloaded to the GM in the "Key Download" message. Also, 
to avoid replay attacks, this sequence number is never reset to a 
lower value (i.e., rollover to zero) as long as the group identifier 
remains valid and in use. The GO MUST preserve this sequence number 
across re-boots. 
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4.4.4. Discovery of GC/KS 


Potential GMs will receive notice of the new group via some 
mechanism: announcement, Anycast, or registration look-up. The GM 
will send an RTJ to the GC/KS. 


4.4.5. GC/KS Registration Policy Enforcement 


The GC/KS may or may not require cookies, depending on the DoS 
environment and the local configuration. 


Once the RTJ has been received, the GC/KS will verify that the GM is 
allowed to have access to the group keys. The GC/KS will then verify 
the signature on the RTJ to ensure it was sent by the claimed 
identity. If the checks succeed, the GC/KS will ready a Key Download 
message for the GM. If not, the GC/KS can notify the GM of a non- 
security-relevant problem. 


4.4.6. GM Registration Policy Enforcement 


Upon receipt of the Key Download message, the GM will verify the 
signature on the message. Then the GM will retrieve the PT from the 
Key Download message and verify that the GO created and signed the 
PT. Once the PT is verified as valid, the GM will verify that the 
GC/KS is authorized to distribute key for this group. Then the GM 
will verify that the mechanisms used in the group are available and 
acceptable for protection of the GMs data (assuming the GM is a data 
source). The GM will then accept membership in this group. 


The GM will then check to see if it is allowed to be a S-GC/KS for 
this group. If the GM is allowed to be a S-GC/KS AND the local GM 
configuration allows the GM to act as a S-GC/KS for this group, then 
the GM changes its operating state to S-GC/KS. The GO needs to 
assign the authority to become a S-GC/KS in a manner that supports 
the overall group integrity and operations. 


4.4.7. Autonomous Distributed GSAKMP Operations 


In autonomous mode, each S-GC/KS operates a largely self-contained 
sub-group for which the Primary-GC/KS delegates the sub-group’s 
membership management responsibility to the S-GC/KS. In general, the 
S-GC/KS locally handles each Group Member’s registration and 
de-registration without any interaction with the Primary-GC/KS. 
Periodically, the Primary-GC/KS multicasts a Rekey Event message 
addressed only to its one or more S-GC/KS. 


After a S-GC/KS successfully processes a Rekey Event message from the 
Primary-GC/KS, the S-GC/KS transmits to its sub-group its own Rekey 
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Event message containing a copy of the group's new GTPK and policy 
token. The S-GC/KS encrypts its Rekey Event message’s sub-group key 
management information using Logical Key Hierarchy or a comparable 
rekey protocol. The S-GC/KS uses the rekey protocol to realize 
forward and backward secrecy, such that only the authorized sub-group 
members can decrypt and acquire access to the new GTPK and policy 
token. The frequency at which the Primary-GC/KS transmits a Rekey 
Event message is a policy token parameter. 


For the special case of a S-GC/KS detecting an expelled or 
compromised group member, a mechanism is defined to trigger an 
immediate group rekey rather than wait for the group's rekey period 
to elapse. See below for details. 


Each S-GC/KS will be registered by the GC/KS as a management node 
with responsibility for GTPK distribution, access control policy 
enforcement, LKH tree creation, and distribution of LKH key arrays. 
The S-GC/KS will be registered into the primary LKH tree as an 
endpoint. Each S-GC/KS will hold an entire LKH key array for the 
GC’s LKH key tree. 


For the purpose of clarity, the process of creating a distributed 
GSAKMP group will be explained in chronological order. 


First, the Group Owner will create a policy token that authorizes a 
subset of the group's membership to assume the role of S-GC/KS. 


The GO needs to ensure that the S-GC/KS rules in the policy token 
will be stringent enough to ensure trust in the S-GC/KSes. This 
policy token is handed off to the primary GC. 


The GC will create the GTPK and initial LKH key tree. The GC will 
then wait for a potential S-GC/KS to send a Request to Join (RTJ) 
message. 


A potential S-GC/KS will eventually send an RTJ. The GC will enforce 
the access control policy as defined in the policy token. The 
S-GC/KS will accept the role of S-GC/KS and create its own LKH key 
tree for its sub-group membership. 


The S-GC/KS will then offer registration services for the group. 
There are local management decisions that are optional to control the 
scope of group members that can be served by a S-GC/KS. These are 
truly local management issues that allow the administrators of an 
S-GC/KS to restrict service to potential GMs. These local controls 
do not affect the overall group security policy, as defined in the 
policy token. 
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A potential Group Member will send an RTJ to the S-GC/KS. The 
S-GC/KS will enforce the entire access control policy as defined in 
the PT. The GM will receive an LKH key array that corresponds to the 
LKH tree of the S-GC/KS. The key tree generated by the S-GC/KS is 
independent of the key tree generated by the GC/KS; they share no 
common keys. 


The GM then has the keys it needs to receive group traffic and be 
subject to rekey from the S-GC/KS. For the sake of this discussion, 
let's assume the GM is to be expelled from the group membership. 


The S-GC/KS will receive notification that the GM is to be expelled. 
This mechanism is outside the scope of this protocol. 


Upon notification that a GM that holds a key array within its LKH 
tree is to be expelled, the S-GC/KS does two things. First, the 
S-GC/KS initiates a de-registration exchange with the GC/KS 
identifying the member to be expelled. (The S-GC/KS proxies a Group 
Member’s de-registration informing the GC/KS that the Group Member 
has been expelled from the group.) Second, the S-GC/KS will wait for 
a rekey action by the GC/KS. The immediacy of the rekey action by 
the GC/KS is a management decision at the GC/KS. Security is best 
served by quick expulsion of untrusted members. 


Upon receipt of the de-registration notification from the S-GC/KS, 
the GC/KS will register the member to be expelled. The GC/KS will 
then follow group procedure for initiating a rekey action (outside 
the scope of this protocol). The GC/KS will communicate to the GO 
the expelled member’s information (outside the scope of this 
protocol). With this information, the GO will create a new PT for 
the group with the expelled GM identity added to the excluded list in 
the group’s access control rules. The GO provides this new PT to the 
GC/KS for distribution with the Rekey Event Message. 


The GC/KS will send out a rekey operation with a new PT. The S-GC/KS 
will receive the rekey and process it. At the same time, all other 
S-GC/KSes will receive the rekey and note the excluded GM identity. 
All S-GC/KSes will review local identities to ensure that the 
excluded GM is not a local member. If it is, then the S-GC/KS will 
create a rekey message. The S-GC/KSes must always create a rekey 
message, whether or not the expelled Group Member is a member of 
their subtrees. 


The S-GC/KS will then create a local rekey message. The S-GC/KS will 
send the wrapped Group TPK to all members of its local LKH tree, 
except the excluded member(s). 
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5. 


De 


Group Life Cycle 


The management of a cryptographic group follows a life cycle: group 
definition, group establishment, and security-relevant group 
maintenance. Group definition involves defining the parameters 
necessary to support a secure group, including its policy token. 
Group establishment is the process of granting access to new members. 
Security-relevant group maintenance messages include rekey, policy 
changes, member deletions, and group destruction. Each of these life 
cycle phases is discussed in the following sections. 


The use and processing of the optional Vendor ID payload for all 
messages Can be found in Section 7.10. 


1. Group Definition 


A cryptographic group is established to support secure communications 
among a group of individuals. The activities necessary to create a 
policy token in support of a cryptographic group include: 


- Determine Access Policy: identify the entities that are authorized 
to receive the group key. 


- Determine Authorization Policy: identify which entities are 
authorized to perform security-relevant actions, including key 
dissemination, policy creation, and initiation of security- 
management actions. 


- Determine Mechanisms: define the algorithms and protocols used by 
GSAKMP to secure the group. 


- Create Group Policy Token: format the policies and mechanisms into 
a policy token, and apply the GO signature. 


.2. Group Establishment 


GSAKMP Group Establishment consists of three mandatory-to-implement 
messages: the Request to Join, the Key Download, and the Key Download 
Ack/Failure. The exchange may also include two OPTIONAL error 
messages: the Request to Join Error and the Lack_of_Ack messages. 
Operation using the mandatory messages only is referred to as "Terse 
Mode", while inclusion of the error messaging is referred to as 
"Verbose Mode". GSAKMP implementations MUST support Terse Mode and 
MAY support Verbose Mode. Group Establishment is discussed in 
Section 5.2.1. 
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A group is set in Terse or Verbose Mode by a policy token parameter. 
All (S-)GC/KSes in a Verbose Mode group MUST support Verbose Mode. 
GSAKMP allows Verbose Mode groups to have GMs that do not support 
Verbose Mode. Candidate GMs that do not support Verbose Mode and 
receive a RTJ-Error or Lack-of-Ack message must handle these messages 
gracefully. Additionally, a GM will not know ahead of time that it 
is interacting with the (S-)GC/KS in Verbose or Terse Mode until the 
policy token is received. 


For denial of service protection, a Cookie Exchange MAY precede the 
Group Establishment exchange. The Cookie Exchange is described in 
Section 5.2.2. 


Regardless of mode, any error message sent between component members 
indicates the first error encountered while processing the message. 


5.2.1. Standard Group Establishment 


After the out-of-band receipt of a policy token, a potential Group 
Controller Key Server (GC/KS) verifies the token and its eligibility 
to perform GC/KS functionality. It is then permitted to create any 
needed group keys and begin to establish the group. 


The GSAKMP Ladder Diagram, Figure 1, illustrates the process of 
establishing a cryptographic group. The left side of the diagram 
represents the actions of the GC/KS. The right side of the diagram 


represents the actions of the GMs. The components of each message 
shown in the diagram are presented in Sections 5.2.1.1 through 
sgl ao 
CONTROLLER Mandatory/ MESSAGE MEMBER 
Optional 
!<-M---------— Request to Join------------- 
<Process> ! ! 
<RTJ> ! ! 
!--M----------— Key Download---=-===========-= >! 


I<Process KeyDL> 
!--Q------- Request to Join Error--------- >! or 

! ! <Proc RIJ-Err> 
!<-M----Key Download - Ack/Failure-------- J 


<Process >! ! 
<KeyDL-A/F>! ! 
| ==D====-=- Lack of Acknowledgement--------= >! 
! ! <Proc LOA> 
|<=======SHARED KEYED GROUP SESSION======>! 


Figure 1: GSAKMP Ladder Diagram 
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The Request to Join message is sent from a potential GM to the GC/KS 
to request admission to the cryptographic group. The message 
contains key creation material, freshness data, an optional selection 
of mechanisms, and the signature of the GM. 


The Key Download message is sent from the GC/KS to the GM in response 
to an accepted Request to Join. This GC/KS-signed message contains 
the identifier of the GM, freshness data, key creation material, 
encrypted keys, and the encrypted policy token. The policy token is 
used to facilitate well-ordered group creation and MUST include the 
groups identification, group permissions, group join policy, group 
controller key server identity, group management information, and 
digital signature of the GO. This will allow the GM to determine 
whether group policy is compatible with local policy. 


The Request to Join Error message is sent from the GC/KS to the GM in 
response to an unaccepted Request to Join. This message is not 
signed by the GC/KS for two reasons: 1) the GM, at this point, has no 
knowledge of who is authorized to act as a GC/KS, and so the 
signature would thus be meaningless to the GM, and 2) signing 
responses to denied join requests would provide a denial of service 
potential. The message contains an indication of the error 
condition. The possible values for this error condition are: 
Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID, Invalid- 
Sequence-ID, Payload-Malformed, Invalid-ID-Information, Invalid- 
Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority, 
Authentication-Failed, Certificate-Unavailable, Unauthorized-Request, 
Prohibited-by-Group-Policy, and Prohibited-by-Locally-Configured- 
Policy. 


The Key Download Ack/Failure message indicates Key Download receipt 
status at the GM. It is a GM-signed message containing freshness 
data and status. 


The Lack_of_Ack message is sent from the GC/KS to the GM in response 
to an invalid or absent Key Download Ack/Failure message. The signed 
message contains freshness and status data and is used to warn the GM 
of impending eviction from the group if a valid Key Download 
Ack/Failure is not sent. Eviction means that the member will be 
excluded from the group after the next Rekey Event. The policy of 
when a particular group needs to rekey itself is stated in the policy 
token. Eviction is discussed further in Section 5.3.2.1. 


For the following message structure sections, details about payload 
format and processing can be found in Section 7. Each message is 
identified by its exchange type in the header of the message. Nonces 
MUST be present in the messages unless synchronization time is 
available to the system. 
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5.2.1.1. Request to Join 
The exchange type for Request to Join is eight (8). 
The components of a Request to Join Message are shown in Table 1. 
Table 1: Request to Join (RTJ) Message Definition 


Message Name : Request to Join (RTJ) 
Dissection : {HDR-GrpID, Key Creation, Nonce_I, [VendorID], 
: [Notif_Mechanism_Choices], [Notif_Cookiel, 
: [Notif_IPValue]} SigM, [Cert] 
Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor 
ID], Signature, [Certificatel, [Notifications] 


SigM : Signature of Group Member 
Cert : Necessary Certificates, zero or more 
{}Sigx : Indicates fields used in Signature 


[] : Indicate an optional data item 


As shown by Figure 1, a potential GM MUST generate and send an RTJ 
message to request permission to join the group. At a minimum, the 
GM MUST be able to manually configure the destination for the RTJ. 

As defined in the dissection of the RTJ message, this message MUST 
contain a Key Creation payload for KEK determination. A Nonce 
payload MUST be included for freshness and the Nonce_I value MUST be 
saved for potential later use. The GC/KS will use this supplied 
nonce only if the policy token for this group defines the use of 
nonces versus synchronization time. An OPTIONAL Notification payload 
of type Mechanism Choices MAY be included to identify the mechanisms 
the GM wants to use. Absence of this payload will cause the GC/KS to 
select appropriate default policy-token-specified mechanisms for the 
Key Download. 


In response, the GC/KS accepts or denies the request based on local 
configuration. <Process RTJ> indicates the GC/KS actions that will 
determine if the RTJ will be acted upon. The following checks SHOULD 
be performed in the order presented. 


In this procedure, the GC/KS MUST verify that the message header is 
properly formed and confirm that this message is for this group by 
checking the value of the GroupID. If the header checks pass, then 
the identity of the sender is extracted from the Signature payload. 
This identity MUST be used to perform access control checks and find 
the GMs credentials (e.g., certificate) for message verification. It 
MUST also be used in the Key Download message. Then, the GC/KS will 
verify the signature on the message to ensure its authenticity. The 
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GC/KS MUST use verified and trusted authentication material from a 
known root. If the message signature verifies, the GC/KS then 
confirms that all required payloads are present and properly 
formatted based upon the mechanisms announced and/or requested. If 
all checks pass, the GC/KS will create and send the Key Download 
message as described in Section 5.2.1.2. 


If the GM receives no response to the RTJ within the GM’s locally 
configured timeout value, the GM SHOULD resend the RTJ message up to 
three (3) times. 


NOTE: At any one time, a GC/KS MUST process no more than one (1) 
valid RTJ message from a given GM per group until its pending 
registration protocol exchange concludes. 


If any error occurs during RTJ message processing, and the GC/KS is 
running in Terse Mode, the registration session MUST be terminated, 
and all saved state information MUST be cleared. 


The OPTIONAL Notification payload of type Cookie is discussed in 
Section 5.2.2. 


The OPTIONAL Notification payload of type IPValue may be used for the 
GM to convey a specific IP value to the GC/KS. 


5.2.1.2. Key Download 
The exchange type for Key Download is nine (9). 
The components of a Key Download Message are shown in Table 2: 
Table 2: Key Download (KeyDL) Message Definition 


Message Name : Key Download (KeyDL) 

Dissection : (HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Key 
Creation, (Policy Token)*, (Key Download)*, 
[VendorID]} SigC, [Cert] 

Payload Types : GSAKMP Header, Identification, [Nonce], Key 
Creation, Policy Token, Key Download, [Vendor 
ID], Signature, [Certificatel 


SigC : Signature of Group Controller Key Server 
Cert : Necessary Certificates, zero or more 
{}Sigx : Indicates fields used in Signature 

[] : Indicate an optional data item 

(data) * : Indicates encrypted information 
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In response to a properly formed and verified RTJ message, the GC/KS 
creates and sends the KeyDL message. As defined in the dissection of 
the message, this message MUST contain payloads to hold the following 
information: GM identification, Key Creation material, encrypted 
policy token, encrypted key information, and signature information. 
If synchronized time is not available, the Nonce payloads MUST be 
included in the message for freshness. 


If present, the nonce values transmitted MUST be the GC/KS’s 
generated Nonce_R value and the combined Nonce_C value that was 
generated by using the GC/KS’s Nonce_R value and the Nonce_I value 
received from the GM in the RTJ. 


If two-party key determination is used, the key creation material 
supplied by the GM and/or the GC/KS will be used to generate the key. 
Generation of this key is dependent on the key exchange, as defined 
in Section 7.11, "Key Creation Payload". The policy token and key 
material are encrypted in the generated key. 


The GM MUST be able to process the Key Download message. <Process 
KeyDL> indicates the GM actions that will determine how the Key 
Download message will be acted upon. The following checks SHOULD be 
performed in the order presented. 


In this procedure, the GM will verify that the message header is 
properly formed and confirm that this message is for this group by 
checking the value of the GroupID. If the header checks pass, the GM 
MUST confirm that this message was intended for itself by comparing 
the Member ID in the Identification payload to its identity. 


After identification confirmation, the freshness values are checked. 
If using nonces, the GM MUST use its saved Nonce_I value, extract the 
received GC/KS Nonce_R value, compute the combined Nonce_C value, and 
compare it to the received Nonce_C value. If not using nonces, the 
GM MUST check the timestamp in the Signature payload to determine if 
the message is new. 


After freshness is confirmed, the signature MUST be verified to 
ensure its authenticity. The GM MUST use verified and trusted 
authentication material from a known root. If the message signature 
verifies, the key creation material is extracted from the Key 
Creation payload to generate the KEK. This KEK is then used to 
decrypt the policy token data. The signature on the policy token 
MUST be verified. Access control checks MUST be performed on both 
the GO and the GC/KS to determine both their authorities within this 
group. After all these checks pass, the KEK can then be used to 
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decrypt and process the key material from the Key Download payload. 
If all is successful, the GM will create and send the Key Download - 
Ack/Failure message as described in Section 5.2.1.4. 


The Policy Token and Key Download Payloads are sent encrypted in the 
KEK generated by the Key Creation Payload information using the 
mechanisms defined in the group announcement. This guarantees that 
the sensitive policy and key data for the group and potential rekey 
data for this individual cannot be read by anyone but the intended 
recipient. 


If any error occurs during KeyDL message processing, regardless of 
whether the GM is in Terse or Verbose Mode, the registration session 
MUST be terminated, the GM MUST send a Key Download - Ack/Failure 
message, and all saved state information MUST be cleared. If in 
Terse Mode, the Notification Payload will be of type NACK to indicate 
termination. If in Verbose Mode, the Notification Payload will 
contain the type of error encountered. 


5.2.1.3. Request to Join Error 
The exchange type for Request to Join Error is eleven (11). 


The components of the Request to Join Error Message are shown in 
Table 3: 


Table 3: Request to Join Error (RTJ-Err) Message Definition 


Message Name : Request to Join Error (RTJ-Err) 
Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID] } 
Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID] 


In response to an unacceptable RTJ, the GC/KS MAY send a Request to 
Join Error (RIJ-Err) message containing an appropriate Notification 
payload. Note that the RTJ-Err message is not a signed message for 
the following reasons: the lack of awareness on the GM’s perspective 
of who is a valid GC/KS as well as the need to protect the GC/KS from 
signing messages and using valuable resources. Following the sending 
of an RTJ-Err, the GC/KS MUST terminate the session, and all saved 
state information MUST be cleared. 


Upon receipt of an RTJ-Err message, the GM will validate the 
following: the GroupID in the header belongs to a group to which the 
GM has sent an RTJ, and, if present, the Nonce_I matches a Nonce_I 
sent in an RTJ to that group. If the above checks are successful, 
the GM MAY terminate the state associated with that GroupID and 
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nonce. The GM SHOULD be capable of receiving a valid KeyDownload 
message for that GroupID and nonce after receiving an RIJ-Err for a 
locally configured amount of time. 


5.2.1.4. Key Download - Ack/Failure 
The exchange type for Key Download - Ack/Failure is four (4). 


The components of the Key Download - Ack/Failure Message are shown in 
Table 4: 


Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition 


Message Name : Key Download - Ack/Failure (KeyDL-A/F) 
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM 
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor 
ID], Signature 
SigM : Signature of Group Member 
{}Sigx : Indicates fields used in Signature 


In response to a properly processed KeyDL message, the GM creates and 
sends the KeyDL-A/F message. As defined in the dissection of the 
message, this message MUST contain payloads to hold the following 
information: Notification payload of type Acknowledgement (ACK) and 
Signature information. If synchronized time is not available, the 
Nonce payload MUST be present for freshness, and the nonce value 
transmitted MUST be the GM’s generated Nonce_C value. If the GM does 
not receive a KeyDL message within a locally configured amount of 
time, the GM MAY send a new RTJ. If the GM receives a valid LOA (see 
Section 5.2.1.5) message from the GC/KS before receipt of a KeyDL 
message, the GM SHOULD send a KeyDL-A/F message of type NACK followed 
by a new RTJ. 


The GC/KS MUST be able to process the KeyDL-A/F message. <Process 
KeyDL-A/F> indicates the GC/KS actions that will determine how the 
KeyDL-A/F message will be acted upon. The following checks SHOULD be 
performed in the order presented. 


In this procedure, the GC/KS will verify that the message header is 
properly formed and confirm that this message is for this group by 
checking the value of the GroupID. If the header checks pass, the 
GC/KS MUST check the message for freshness. If using nonces, the 
GC/KS MUST use its saved Nonce_C value and compare it for equality 
with the received Nonce_C value. If not using nonces, the GC/KS MUST 
check the timestamp in the Signature payload to determine if the 
message is new. After freshness is confirmed, the signature MUST be 
verified to ensure its authenticity. The GC/KS MUST use verified and 
trusted authentication material from a known root. If the message 
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signature verifies, the GC/KS processes the Notification payload. If 
the notification type is of type ACK, then the registration has 
completed successfully, and both parties SHOULD remove state 
information associated with this GM’s registration. 


If the GC/KS does not receive a KeyDL-A/F message of proper form or 
is unable to correctly process the KeyDL-A/F message, the 
Notification payload type is any value except ACK; or if no KeyDL-A/F 
message is received within the locally configured timeout, the GC/KS 
MUST evict this GM from the group in the next policy-defined Rekey 
Event. The GC/KS MAY send the OPTIONAL Lack_of_Ack message if 
running in Verbose Mode as defined in Section 5.2.1.5. 


5.2.1.5. Lack of Ack 
The exchange type for Lack of Ack is twelve (12). 
The components of a Lack of Ack Message are shown in Table 5: 
Table 5: Lack of Ack (LOA) Message Definition 
Message Name : Lack of Ack (LOA) 
Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], 
Notification, [VendorID]} SigC, [Cert] 


Payload Types : GSAKMP Header, Identification, [Nonce], 
Notification, [Vendor ID], Signature, 


[Certificate] 
SigC : Signature of Group Controller Key Server 
Cert : Necessary Certificates, zero or more 
{}Sigx : Indicates fields used in Signature 


[] : Indicate an optional data item 


If the GC/KS's local timeout value expires prior to receiving a 
KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message to 
the GM. As defined in the dissection of the message, this message 
MUST contain payloads to hold the following information: GM 
identification, Notification of error, and signature information. 


If synchronized time is not available, the Nonce payloads MUST be 
present for freshness, and the nonce values transmitted MUST be the 
GC/KS’s generated Nonce_R value and the combined Nonce_C value which 
was generated by using the GC/KS’s Nonce_R value and the Nonce_I 
value received from the GM in the RTJ. These values were already 
generated during the Key Download message phase. 
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The GM MAY be able to process the LOA message based upon local 
configuration. <Process LOA> indicates the GM actions that will 
determine how the LOA message will be acted upon. The following 
checks SHOULD be performed in the order presented. 


In this procedure, the GM MUST verify that the message header is 
properly formed and confirm that this message is for this group by 
checking the value of the GroupID. If the header checks pass, the GM 
MUST confirm that this message was intended for itself by comparing 
the Member ID in the Identification payload to its identity. After 
identification confirmation, the freshness values are checked. If 
using nonces, the GM MUST use its save Nonce_I value, extract the 
received GC/KS Nonce_R value, compute the combined Nonce_C value, and 
compare it to the received Nonce_C value. If not using nonces, the 
GM MUST check the timestamp in the Signature payload to determine if 
the message is new. After freshness is confirmed, access control 
checks MUST be performed on the GC/KS to determine its authority 
within this group. Then signature MUST be verified to ensure its 
authenticity, The GM MUST use verified and trusted authentication 
material from a known root. 


If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that 
session. 


5.2.2. Cookies: Group Establishment with Denial of Service Protection 


This section defines an OPTIONAL capability that MAY be implemented 
into GSAKMP when using IP-based groups. The information in this 
section borrows heavily from [IKEv2] as this protocol has already 
worked through this issue and GSAKMP is copying this concept. This 
section will contain paraphrased sections of [IKEv2] modified for 
GSAKMP to define the purpose of Cookies. 


An optional Cookie mode is being defined for the GSAKMP to help 
against DoS attacks. 


The term "cookies" originates with Karn and Simpson [RFC2522] in 
Photuris, an early proposal for key management with IPSec. The 
ISAKMP fixed message header includes two eight-octet fields titled 
"cookies". Instead of placing this cookie data in the header, in 
GSAKMP this data is moved into a Notification payload. 


An expected attack against GSAKMP is state and CPU exhaustion, where 
the target GC/KS is flooded with Request to Join requests from forged 
IP addresses. This attack can be made less effective if a GC/KS 
implementation uses minimal CPU and commits no state to the 
communication until it knows the initiator potential GM can receive 
packets at the address from which it claims to be sending them. To 
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accomplish this, the GC/KS (when operating in Cookie mode) SHOULD 
reject initial Request to Join messages unless they contain a 
Notification payload of type "cookie". It SHOULD instead send a 
Cookie Download message as a response to the RTJ and include a cookie 
in a notify payload of type Cookie _ Required. Potential GMs who 
receive such responses MUST retry the Request to Join message with 
the responder-GC/KS-supplied cookie in its notification payload of 
type Cookie, as defined by the optional Notification payload of the 


Request to Join Msg in Section 5.2.1.1. This initial exchange will 
then be as shown in Figure 2 with the components of the new message 
Cookie Download shown in Table 6. The exchange type for Cookie 


Download is ten (10). 


CONTROLLER MESSAGE MEMBER 
in Cookie Mode 
!<--Request to Join without Cookie Info---! 
<Gen Cookie>! ! 
<Response >! ! 


VAR sass Cookie Download--------------- >! 
! ! <Process CD> 
!<----Request to Join with Cookie Info----! 

<Process> ! ! 

<RTJ >! ! 
[=== anton lan Key Download--------------- >! 
! ! <Proc KeyDL> 
| <= Key Download - Ack/Failure-------- ! 

<Process >! ! 

<KeyDL-A/F>! ! 
|<=======SHARED KEYED GROUP SESSION======>! 


Figure 2: GSAKMP Ladder Diagram with Cookies 


Table 6: Cookie Download Message Definition 


Message Name : Cookie Download 
Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]} 
Payload Types : GSAKMP Header, Notification, [Vendor ID] 


The first two messages do not affect any GM or GC/KS state except for 
communicating the cookie. 


A GSAKMP implementation SHOULD implement its GC/KS cookie generation 
in such a way as not to require any saved state to recognize its 
valid cookie when the second Request to Join message arrives. The 
exact algorithms and syntax they use to generate cookies does not 
affect interoperability and hence is not specified here. 
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The following is an example of how an endpoint could use cookies to 
implement limited DoS protection. 


A good way to do this is to set the cookie to be: 
Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>) 


where <secret> is a randomly generated secret known only to the 
responder GC/KS and periodically changed, Ni is the nonce value taken 
from the initiator potential GM, and IPi is the asserted IP address 
of the candidate GM. The IP address is either the IP header’s source 
IP address or else the IP address contained in the optional 
Notification "IPvalue" payload (if it is present). 
<SecretVersionNumber> should be changed whenever <secret> is 
regenerated. The cookie can be recomputed when the "Request to Join 
with Cookie Info" arrives and compared to the cookie in the received 
message. If it matches, the responder GC/KS knows that all values 
have been computed since the last change to <secret> and that IPi 
MUST be the same as the source address it saw the first time. 
Incorporating Ni into the hash assures that an attacker who sees only 
the Cookie Download message cannot successfully forge a "Request to 
Join with Cookie Info" message. This Ni value MUST be the same Ni 
value from the original "Request to Join" message for the calculation 
to be successful. 


If a new value for <secret> is chosen while connections are in the 
process of being initialized, a "Request to Join with Cookie Info" 
might be returned with a <SecretVersionNumber> other than the current 
one. The responder GC/KS in that case MAY reject the message by 
sending another response with a new cookie, or it MAY keep the old 
value of <secret> around for a short time and accept cookies computed 
from either one. The responder GC/KS SHOULD NOT accept cookies 
indefinitely after <secret> is changed, since that would defeat part 
of the denial of service protection. The responder GC/KS SHOULD 
change the value of <secret> frequently, especially if under attack. 


An alternative example for Cookie value generation in a NAT 
environment is to substitute the IPi value with the IPValue received 
in the Notification payload in the RTJ message. This scenario is 
indicated by the presence of the Notification payload of type 
IPValue. With this substitution, a calculation similar to that 
described above can be used. 
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5.2.3. Group Establishment for Receive-Only Members 


This section describes an OPTIONAL capability that may be implemented 
in a structured system where the authorized (S-)GC/KS is known in 
advance through out-of-band means and where synchronized time is 
available. 


Unlike Standard Group Establishment, in the Receive-Only system, the 
GMs and (S-)GC/KSes operate in Terse Mode and exchange one message 
only: the Key Download. Potential new GMs do not send an RTJ. 
(S-)GC/KSes do not expect Key Download - ACK/Failure messages and do 
not remove GMs for lack or receipt of the message. 


Operation is as follows: upon notification via an authorized out-of- 
band event, the (S-)GC/KS forms and sends a Key Download message to 
the new member with the Nonce payloads ABSENT. The GM verifies 


- the ID payload identifies that GM 
- the timestamp in the message is fresh 
- the message is signed by an authorized (S-)GC/KS 
- the signature on the message verifies 
When using a Diffie-Hellman Key Creation Type for receive-only 
members, a static-ephemeral model is assumed: the Key Creation 
payload in the Key Download message contains the (S-)GC/KS's public 
component. The member’s public component is assumed to be obtained 
through secure out-of-band means. 

5.3. Group Maintenance 
The Group Maintenance phase includes member joins and leaves, group 


rekey activities, policy updates, and group destruction. These 
activities are presented in the following sections. 


5.3.1. Group Management 

5.3.1.1. Rekey Events 
A Rekey Event is any action, including a compromise report or key 
expiration, that requires the creation of a new group key and/or 
rekey information. 
Once an event has been identified (as defined in the group security 


policy token), the GC/KS MUST create and provide a signed message 
containing the GTPK and rekey information to the group. 
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Each GM who receives this message MUST verify the signature on the 
message to ensure its authenticity. If the message signature does 
not verify, the message MUST be discarded. Upon verification, the GM 
will find the appropriate rekey download packet and decrypt the 
information with a stored rekey key(s). If a new Policy Token is 
distributed with the message, it MUST be encrypted in the old GTPK. 


The exchange type for Rekey Event is five (5). 
The components of a Rekey Event message are shown in Table 7: 
Table 7: Rekey Event Message Definition 
Message Name : Rekey Event 
Dissection : (HDR-GrpID, ([Policy Token])*, Rekey Array, 
[VendorID]}SigC, [Cert] 


Payload Types : GSAKMP Header, [Policy Token], Rekey Event, 
[Vendor ID], Signature, [Certificate], 


SigC : Signature of Group Controller Key Server 
Cert : Necessary Certificates, zero or more 
{}SigX : Indicates fields used in Signature 

(data) * : Indicates encrypted information 


[] : Indicate an optional data item 
5.3.1.2. Policy Updates 


New policy tokens are sent via the Rekey Event message. These policy 
updates may be coupled with an existing rekey event or may be sent in 
a message with the Rekey Event Type of the Rekey Event Payload set to 
None (0) (see Section 7.5.1). 


A policy token MUST NOT be processed if the processing of the Rekey 
Event message carrying it fails. Policy token processing is type 
dependent and is beyond the scope of this document. 


5.3.1.3. Group Destruction 


Group destruction is also accomplished via the Rekey Event message. 
In a Rekey Event message for group destruction, the Sequence ID is 
set to OxFFFFFFFF. Upon receipt of this authenticated Rekey Event 
message, group components MUST terminate processing of information 
associated with the indicated group. 
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5.3.2. Leaving a Group 


There are several conditions under which a member will leave a group: 
eviction, voluntary departure without notice, and voluntary departure 
with notice (de-registration). Each of these is discussed in this 
section. 


5.3.2.1. Eviction 


At some point in the group's lifetime, it may be desirable to evict 
one or more members from a group. From a key management viewpoint, 
this involves revoking access to the group's protected data by 
"disabling" the departing members’ keys. This is accomplished with a 
Rekey Event, which is discussed in more detail in Section 5.3.1.1. 
If future access to the group is also to be denied, the members MUST 
be added to a denied access control list, and the policy token’s 
authorization rules MUST be appropriately updated so that they will 
exclude the expelled GM(s). After receipt of a new PT, GMs SHOULD 
evaluate the trustworthiness of any recent application data 
originating from the expelled GM(s). 


5.3.2.2. Voluntary Departure without Notice 


If a member wishes to leave a group for which membership imposes no 
cost or responsibility to that member, then the member MAY merely 
delete local copies of group keys and cease group activities. 


5.3.2.3. De-Registration 


If the membership in the group does impose cost or responsibility to 
the departing member, then the member SHOULD de-register from the 
group when that member wishes to leave. De-registration consists of 
a three-message exchange between the GM and the member’s GC/KS: the 
Request_to_Depart, Departure_Response, and the Departure_Ack. 
Compliant GSAKMP implementations for GMs SHOULD support the de- 
registration messages. Compliant GSAKMP implementations for GC/KSes 
MUST support the de-registration messages. 


5.3.2.3.1. Request to Depart 


The Exchange Type for a Request_to_Depart Message is thirteen (13). 
The components of a Request_to_Depart Message are shown in Table 8. 


Any GM desiring to initiate the de-registration process MUST generate 
and send an RTD message to notify the GC/KS of its intent. As 
defined in the dissection of the RTD message, this message MUST 
contain payloads to hold the following information: the GC/KS 
identification and Notification of the desire to leave the group. 
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When synchronization time is not available to the system as defined 
by the Policy Token, a Nonce payload MUST be included for freshness, 
and the Nonce_T value MUST be saved for later use. This message MUST 
then be signed by the GM. 


Table 8: Request_to_Depart (RTD) Message Definition 


Message Name : Request_to_Depart (RTD) 

Dissection : {HDR-GrpID, GC/KS_ID, [Nonce_I], Notif_Leave_Group, 
[VendorID]} SigM, [Cert] 

Payload Types : GSAKMP Header, Identification, [Nonce], 
Notification, [Vendor ID], Signature, 


[Certificate] 
SigM : Signature of Group Member 
Cert : Necessary Certificates, zero or more 
{}Sigx : Indicates fields used in Signature 


[1 : Indicate an optional data item 


Upon receipt of the RTD message, the GC/KS MUST verify that the 
message header is properly formed and confirm that this message is 
for this group by checking the value of the GroupID. If the header 
checks pass, then the identifier value in Identification payload is 
compared to its own, the GC/KS's identity, to confirm that the GM 
intended to converse with this GC/KS, the GC/KS who registered this 
member into the group. Then the identity of the sender is extracted 
from the Signature payload. This identity MUST be used to confirm 
that this GM is a member of the group serviced by this GC/KS. Then 
the GC/KS will confirm from the Notification payload that the GM is 
requesting to leave the group. Then the GC/KS will verify the 
signature on the message to ensure its authenticity. The GC/KS MUST 
use verified and trusted authentication material from a known root. 
If all checks pass and the message is successfully processed, then 
the GC/KS MUST form a Departure_Response message as defined in 
Section 531.2432 5 


If the processing of the message fails, the de-registration session 
MUST be terminated, and all state associated with this session is 
removed. If the GC/KS is operating in Terse Mode, then no error 
message is sent to the GM. If the GC/KS is operating in Verbose 
Mode, then the GC/KS sends a Departure_Response Message with a 
Notification Payload of type Request_to_Depart_Error. 
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5.3.2.3.2. Departure_Response 


The Exchange Type for a Departure_Response Message is fourteen (14). 
The components of a Departure_Response Message are shown in Table 9. 


In response to a properly formed and verified RTD message, the GC/KS 
MUST create and send the DR message. As defined in the dissection of 
the message, this message MUST contain payloads to hold the following 
information: GM identification, Notification for acceptance of 


departure, and signature information. If synchronization time is not 
available, the Nonce payloads MUST be included in the message for 
freshness. 


Table 9: Departure_Response (DR) Message Definition 


Message Name : Departure_Response (DR) 

Dissection : {HDR-GrpID, Member_ID, [Nonce_R, Nonce_C], 
Notification, [VendorID]} SigC, [Cert] 

Payload Types : GSAKMP Header, Identification, [Nonce], 
Notification, [Vendor ID], Signature, 


[Certificate] 
SigC : Signature of Group Member 
Cert : Necessary Certificates, zero or more 
{}Sigx : Indicates fields used in Signature 


[] : Indicate an optional data item 


If present, the nonce values transmitted MUST be the GC/KS's 
generated Nonce_R value and the combined Nonce_C value that was 
generated by using the GC/KS’s Nonce_R value and the Nonce_I value 
received from the GM in the RTD. This Nonce_C value MUST be saved 
relative to this departing GM's ID. 


The GM MUST be able to process the Departure_Response message. The 
following checks SHOULD be performed in the order presented. 


The GM MUST verify that the message header is properly formed and 
confirm that this message is for this group by checking the value of 
the GroupID. If the header checks pass, the GM MUST confirm that 
this message was intended for itself by comparing the Member ID in 
the Identification payload to its identity. After identification 
confirmation, the freshness values are checked. If using nonces, the 
GM MUST use its saved Nonce_I value, extract the received GC/KS 
Nonce_R value, compute the combined Nonce_C value, and compare it for 
equality with the received Nonce_C value. If not using nonces, the 
GM MUST check the timestamp in the signature payload to determine if 
the message is new. After freshness is confirmed, confirmation of 
the identity of the signer of the DR message is the GMs authorized 
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GC/KS is performed. Then, the signature MUST be verified to ensure 
its authenticity. The GM MUST use verified and trusted 
authentication material from a known root. If the message signature 
verifies, then the GM MUST verify that the Notification is of Type 
Departure_Accepted or Request_to_Depart_Error. 


If the processing is successful, and the Notification payload is of 
type Departure_Accepted, the member MUST form the Departure_ACK 
message as defined in Section 5.3.2.3.3. If the processing is 
successful, and the Notification payload is of type 
Request_to_Depart_Error, the member MUST remove all state associated 
with the de-registration session. If the member still desires to 
De-Register from the group, the member MUST restart the de- 
registration process. 


If the processing of the message fails, the de-registration session 
MUST be terminated, and all state associated with this session is 
removed. If the GM is operating in Terse Mode, then a Departure_Ack 
Message with Notification Payload of type NACK is sent to the GC/KS. 
If the GM is operating in Verbose Mode, then the GM sends a 
Departure_Ack Message with a Notification Payload of the appropriate 
failure type. 


5.3.2.3.3. Departure_ACK 


The Exchange Type for a Departure_ACK Message is fifteen (15). The 
components of the Departure_ACK Message are shown in Table 10: 


Table 10: Departure_ACK (DA) Message Definition 


Message Name : Departure_ACK (DA) 
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM 
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor 
ID], Signature 
SigM : Signature of Group Member 
{}Sigx : Indicates fields used in Signature 


In response to a properly processed Departure_Response message, the 
GM MUST create and send the Departure_ACK message. As defined in the 
dissection of the message, this message MUST contain payloads to hold 
the following information: Notification payload of type 
Acknowledgement (ACK) and signature information. If synchronization 
time is not available, the Nonce payload MUST be present for 
freshness, and the nonce value transmitted MUST be the GM’s generated 
Nonce_C value. 
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Upon receipt of the Departure_ACK, the GC/KS MUST perform the 
following checks. These checks SHOULD be performed in the order 
presented. 


In this procedure, the GC/KS MUST verify that the message header is 
properly formed and confirm that this message is for this group by 
checking the value of the GroupID. If the header checks pass, the 
GC/KS MUST check the message for freshness. If using nonces, the 
GC/KS MUST use its saved Nonce_C value and compare it to the received 
Nonce_C value. If not using nonces, the GC/KS MUST check the 
timestamp in the signature payload to determine if the message is 
new. After freshness is confirmed, the signature MUST be verified to 
ensure its authenticity. The GC/KS MUST use verified and trusted 
authentication material from a known root. If the message signature 
verifies, the GC/KS processes the Notification payload. If the 
notification type is of type ACK, this is considered a successful 
processing of this message. 


If the processing of the message is successful, the GC/KS MUST remove 
the member from the group. This MAY involve initiating a Rekey Event 
for the group. 


If the processing of the message fails or if no Departure_Ack is 
received, the GC/KS MAY issue a LOA message. 


6. Security Suite 


The Security Definition Suite 1 MUST be supported. Other security 
suite definitions MAY be defined in other Internet specifications. 


6.1. Assumptions 


All potential GMs will have enough information available to them to 
use the correct Security Suite to join the group. This can be 
accomplished by a well-known default suite, ‘Security Suite 1’, or by 
announcing/posting another suite. 


6.2. Definition Suite 1 
GSAKMP implementations MUST support the following suite of algorithms 
and configurations. The following definition of Suite 1 borrows 
heavily from IKE’s Oakley group 2 definition and Oakley itself. 
The GSAKMP Suite 1 definition gives all the algorithm and 


cryptographic definitions required to process group establishment 
messages. It is important to note that GSAKMP does not negotiate 
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these cryptographic mechanisms. This definition is set by the Group 
Owner via the Policy Token (passed during the GSAKMP exchange for 
member verification purposes). 


The GSAKMP Suite 1 definition is: 


Key download and Policy Token encryption algorithm definition: 
Algorithm: AES 

Mode: CBC 

Key Length: 128 bits 


Policy Token digital signature algorithm is: 
DSS-ASN1-DER 
Hash algorithm is: 
SHA-1 


Nonce Hash algorithm is: 
SHA-1 


The Key Creation definition is: 

Algorithm type is Diffie Hellman 

MODP group definition 

g: 2 

p: "FFFFFFFF FFFFFFFF C9OFDAA2 2168C234 C4C6628B 80DC1CD1" 
"29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD" 
"EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245" 
"E485B576 625E7EC6 F44C42E9 A637ED6B OBFF5CB6 F406B7ED" 
"EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381" 
"FFFFFFFF FFFFFFFF" 


NOTE: The p and g values come from IKE [RFC2409], Section 6.2, 
"Second Oakley Group", and p is 1024 bits long. 


The GSAKMP message digital signature algorithm is: 
DSS-SHA1-ASN1-DER 


The digital signature ID type is: 
ID-DN-STRING 
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7.  GSAKMP Payload Structure 


A GSAKMP Message is composed of a GSAKMP Header (Section 7.1) 
followed by at least one GSAKMP Payload. All GSAKMP Payloads are 
composed of the Generic Payload Header (Section 7.2) followed by the 
specific payload data. The message is chained by a preceding payload 
defining its succeeding payload. Payloads are not required to be in 
the exact order shown in the message dissection in Section 5, 
provided that all required payloads are present. Unless it is 
explicitly stated in a dissection that multiple payloads of a single 
type may be present, no more than one payload of each type allowed by 
the message may appear. The final payload in a message will point to 
no succeeding payload. 


All fields of type integer in the Header and Payload structure that 
are larger than one octet MUST be converted into Network Byte Order 
prior to data transmission. 


Padding of fields MUST NOT be done as this leads to processing 
errors. 


When a message contains a Vendor ID payload, the processing of the 
payloads of that message is modified as defined in Section 7.10. 


7.1.  GSAKMP Header 
7.1.1. (GSAKMP Header Structure 
The GSAKMP Header fields are shown in Figure 3 and defined as: 


0 1 2 3 
01234567890123456789012345678090 m1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
GroupID Type ! GroupID Length! Group ID Value 7 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


— + 


t+ 


hdd dh dd $ e $ + q — dd $ + 4 q ++ +++ +++ ++ +++ 
! Next Payload ! Version ! Exchange Type ! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Sequence ID ! 
hd dh + hd $ + q $ + q dd $ + 4 q ++ +++ ++ +++ +++ 
Length ! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- $ + 4 q ++ +++ ++ +++ +++ 


is E y 


+ 


Figure 3: GSAKMP Header Format 
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Group Identification Type (1 octet) - Table 11 presents the group 
identification types. This field is treated as an unsigned 
value. 


Table 11: Group Identification Types 


Grp ID Type Value Description 

Reserved 0 

UTF-8 1 Format defined in Section 7.1.1.1.1. 

Octet String 2 This type MUST be implemented. 

Format defined in Section 7.1.1.1.2. 

IPv4 3 Format defined in Section 7.1.1.1.3. 

IPv6 4 Format defined in Section 7.1.1.1.4. 

Reserved to IANA 59-192 

Private Use 193 - 255 

Group Identification Length (1 octet) - Length of the Group 
Identification Value field in octets. This value MUST NOT be 
zero (0). This field is treated as an unsigned value. 

Group Identification Value (variable length) - Indicates the 


name/title of the group. All GroupID types should provide unique 
naming across groups. GroupID types SHOULD provide this 
capability by including a random element generated by the creator 
(owner) of the group of at least eight (8) octets, providing 
extremely low probability of collision in group names. The 
GroupID value is static throughout the life of the group. 


Next Payload (1 octet) - Indicates the type of the next payload in 
the message. The format for each payload is defined in the 
following sections. Table 12 presents the payload types. This 
field is treated as an unsigned value. 
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Table 12: Payload Types 


Next_Payload_Type Value 


None 

Policy Token 

Key Download Packet 
Rekey Event 
Identification 
Reserved 
Certificate 
Reserved 

Signature 
Notification 
Vendor ID 10 
Key Creation 1:1 
Nonce 12 
Reserved to IANA 13 - 192 
Private Use 193 +2255 


OmMDAITHDUOAWNEFR OO 


- Indicates the version of the GSAKMP protocol in 


use. The current value is one (1). This field is treated as an 
unsigned value. 


Exchange Type (1 octet) - Indicates the type of exchange (also known 
as the message type). Table 13 presents the exchange type 
values. This field is treated as an unsigned value. 

Table 13: Exchange Types 
Exchange_Type Value 
Reserved 0 = 3 
Key Download Ack/Failure 4 
Rekey Event 5 
Reserved © => 
Request to Join 8 
Key Download 9 
Cookie Download 10 
Request to Join Error 11 
Lack of Ack 12 
Request to Depart 13 
Departure Response 14 
Departure Ack 15 
Reserved to IANA 16 - 192 
Private Use 193 = 255 
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Sequence ID (4 octets) - The Sequence ID is used for replay 


protection of group management messages. If the message is not a 
group management message, this value MUST be set to zero (0). 
The first value used by a (S-)GC/KS MUST be one (1). For each 
distinct group management message that this (S-)GC/KS transmits, 
this value MUST be incremented by one (1). Receivers of this 
group management message MUST confirm that the value received is 
greater than the value of the sequence ID received with the last 
group management message from this (S-)GC/KS. Group Components 
(e.g., GMs, S-GC/KSes) MUST terminate processing upon receipt of 
an authenticated group management message containing a Sequence 
ID of OxFFFFFFFF. This field is treated as an unsigned integer 
in network byte order. 


Length (4 octets) - Length of total message (header + payloads) in 


Harney, 


octets. This field is treated as an unsigned integer in network 
byte order. 
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7.1.1.1. GroupID Structure 

This section defines the formats for the defined GroupID types. 
Lil + UTES8 

The format for type UTF-8 [RFC3629] is shown in Figure 4. 


0 1 2 3 
0123456789012345678909012345678090m1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Random Value j 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


— + 


c+ 


c+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
UTF-8 String y 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+ + 


+ 


Figure 4: GroupID UTF-8 Format 


Random Value (16 octets) - For the UTF-8 GroupID type, the Random 
Value is represented as a string of exactly 16 hexadecimal digits 
converted from its octet values in network-byte order. The 
leading zero hexadecimal digits and the trailing zero hexadecimal 
digits are always included in the string, rather than being 
truncated. 


UTF-8 String (variable length) - This field contains the human 
readable portion of the GroupID in UTF-8 format. Its length is 
calculated as the (GroupID Length - 16) for the Random Value 
field. The minimum length for this field is one (1) octet. 


Harney, et al. Standards Track [Page 51] 


RFC 4535 


Dede Le 2% 


Octet String 


GSAKMP 


The format for type Octet String is shown in Figure 5. 


0 


1 


2 


June 2006 


3 


OL 23.4 9678 9 OL 2.3 4°56 7.8: 9° 0 123 4°56 7 8.9.01 


+ 


Random Value 


eE 


+ 


Octet String 


+ 


Figure 5: 


Random Value 


Octet String 


GroupID Octet String Format 


(8 octets) 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


- The 8-octet unsigned random value in 
network byte order format. 


portion of the GroupID. 


Length - 8) 


this field is one 


Tall Sis 


(1 


) 


(variable length) 


- This field contains the Octet String 
Its length is calculated as the 
The minimum length for 


octet. 


IPv4 Group Identifier 


for the Random Value field. 


(GroupID 


The format for type IPv4 Group Identifier is shown in Figure 6. 


0 


1 


2 


3 


OL2:345 6789 012345 678 9012 3-4°5 67 8.9 0 1 


+ 


—+-+-4+-+4+-4+-4+-4+-4+-4+ 
Random Value 
—+-+-4+-+4+-4+-4+-4+-4+-4+ 


Df 


—+-+-4+-+4+-4+-4+-4+-4+-4+ 
IPv4 Value 
—+-+-4+-+4+-4+-4+-4+-4+-4+ 


+ 


+ 


+ 


+ 


+ 


+ 


Figure 


Random Value 


IPv4 Value 
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(4 octets) 


=+- 


=+- 


=+- 


=+- 


6: 


(8 octets) 


+ 


+ 


-+-+ 


-+-+ 


-+-+ 


-+-+ 


+ 


+ 


+ 


+ 


=+- 


=+- 


=+- 


=+- 


+ 


+ 


+ 


+ 


=+- 


=+- 


=+- 


=+- 


GroupID IPv4 


- The 8-octet 
network byte order format. 


+-+-+- 


+-+-+- 


+-+-+- 


+-+-+- 


Format 


+ 


+ 


=+- 


=+- 


=+- 


=+- 


+ 


+ 


+ 


+ 


=+- 


=+- 


=+- 


=+- 


unsigned random 


+- 


+- 


+- 


+- 


+ 


+ 


=+- 


=+- 


=+- 


=+- 


value 


+++ 
+++ 
! 
+-+-+ 
! 
+-+-+ 


in 


- The IPv4 value in network byte order format. 
This value MAY contain the multicast address of the group. 
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7.1.1.1.4. IPv6 Group Identifier 
The format for type IPv6 Group Identifier is shown in Figure 7. 


0 1 2 3 
01234567890123456789012345678090m1 
O o o ooo ++ + 
Random Value j 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv6 Value j 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


t+ + toH 


c+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


c+ 


+ 


Figure 7: GroupID IPv6 Format 


Random Value (8 octets) - The 8-octet unsigned random value in 
network byte order format. 


IPv6 Value (16 octets) - The IPv6 value in network byte order format. 
This value MAY contain the multicast address of the group. 


7.1.2. GSAKMP Header Processing 


When processing the GSAKMP Header, the following fields MUST be 
checked for correct values: 


1. Group ID Type - The Group ID Type value MUST be checked to be a 
valid group identification payload type as defined by Table 11. 
If the value is not valid, then an error is logged. If in 
Verbose Mode, an appropriate message containing notification 
value Payload-Malformed will be sent. 


2. GroupID - The GroupID of the received message MUST be checked 
against the valid GroupIDs of the Group Component. If no match 
is found, then an error is logged; in addition, if in Verbose 
Mode, an appropriate message containing notification value 
Invalid-Group-ID will be sent. 
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3. Next Payload - The Next Payload value MUST be checked to be a 
valid payload type as defined by Table 12. If the value is not 
valid, then an error is logged. If in Verbose Mode, an 
appropriate message containing notification value Invalid- 
Payload-Type will be sent. 


4. Version - The GSAKMP version number MUST be checked that its 
value is one (1). For other values, see below for processing. 
The GSAKMP version number MUST be checked that it is consistent 
with the group's policy as specified in its Policy Token. If the 
version is not supported or authorized, then an error is logged. 
If in Verbose Mode, an appropriate message containing 
notification value Invalid-Version will be sent. 


5. Exchange Type - The Exchange Type MUST be checked to be a valid 
exchange type as defined by Table 13 and MUST be of the type 
expected to be received by the GSAKMP state machine. If the 
exchange type is not valid, then an error is logged. If in 
Verbose Mode, an appropriate message containing notification 
value Invalid-Exchange-Type will be sent. 


6. Sequence ID - The Sequence ID value MUST be checked for 
correctness. For negotiation messages, this value MUST be zero 
(0). For group management messages, this value MUST be greater 
than the last sequence ID received from this (S-)GC/KS. Receipt 
of incorrect Sequence ID on group management messages MUST NOT 
cause a reply message to be generated. Upon receipt of incorrect 
Sequence ID on non-group management messages, an error is logged. 
If in Verbose Mode, an appropriate message containing 
notification value Invalid-Sequence-ID will be sent. 


The length fields in the GSAKMP Header (Group ID Length and Length) 
are used to help process the message. If any field is found to be 
incorrect, then an error is logged. If in Verbose Mode, an 
appropriate message containing notification value Payload-Malformed 
will be sent. 


In order to allow a GSAKMP version one (v1) implementation to 
interoperate with future versions of the protocol, some ideas will be 
discussed here to this effect. 


A (S-)GC/KS that is operating in a multi-versioned group as defined 


by the Policy Token can take many approaches on how to interact with 
the GMs in this group for a rekey message. 
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One possible solution is for the (S-)GC/KS to send out multiple rekey 


messages, one per version level that it supports. Then each GM would 
only process the message that has the version at which it is 
operating. 


An alternative approach that all GM vl implementations MUST support 
is the embedding of a vl message inside a version two (v2) message. 
If a GM running at vl receives a GSAKMP message that has a version 
value greater than one (1), the GM will attempt to process the 
information immediately after the Group Header as a Group Header for 
vl of the protocol. If this is in fact a vl Group Header, then the 
remainder of this vl message will be processed in place. After 
processing this vl embedded message, the data following the vl 
message should be the payload as identified by the Next Payload field 
in the original header of the message and will be ignored by the vl 
member. However, if the payload following the initial header is not 
a vl Group Header, then the GM will gracefully handle the 
unrecognized message. 


7.2. Generic Payload Header 
7.2.1. Generic Payload Header Structure 


Each GSAKMP payload defined in the following sections begins with a 
generic header, shown in Figure 8, that provides a payload "chaining" 
capability and clearly defines the boundaries of a payload. The 
Generic Payload Header fields are defined as follows: 


0 1 2 3 
Oud 2: B45 36 T 8 94.0 L 2 8 AS 67 BGO) Te 234. E 7,890: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 8: Generic Payload Header 


Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 
Payload Length (2 octets) - Length in octets of the current payload, 


including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 
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7.2.2. Generic Payload Header Processing 


When processing the Generic Payload Header, the following fields MUST 
be checked for correct values: 


1. Next Payload - The Next Payload value MUST be checked to be a 
valid payload type as defined by Table 12. If the payload type 
is not valid, then an error is logged. If in Verbose Mode, an 
appropriate message containing notification value Invalid- 
Payload-Type will be sent. 


2. RESERVED - This field MUST contain the value zero (0). If the 
value of this field is not zero (0), then an error is logged. If 
in Verbose Mode, an appropriate message containing notification 
value Payload-Malformed will be sent. 


The length field in the Generic Payload Header is used to process the 
remainder of the payload. If this field is found to be incorrect, 
then an error is logged. If in Verbose Mode, an appropriate message 
containing notification value Payload-Malformed will be sent. 


7.3. Policy Token Payload 
7.3.1. Policy Token Payload Structure 


The Policy Token Payload contains authenticatable group-specific 
information that describes the group security-relevant behaviors, 
access control parameters, and security mechanisms. Figure 9 shows 
the format of the payload. 


0 1 2 3 
Od, 2-34.506. 7 89.001 2 3A 16 7 8.9 0--1,2-3 4:09:06: 78-901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Policy Token Type ! Policy Token Data 7 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 9: Policy Token Payload Format 
The Policy Token Payload fields are defined as follows: 
Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 


"chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 
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RESERVED (1 octet) - Unused, set to 0. 


Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 


Policy Token Type (2 octets) - Specifies the type of Policy Token 
being used. Table 14 identifies the types of policy tokens. 
This field is treated as an unsigned integer in network byte 
order format. 


Table 14: Policy Token Types 


Policy_Token_Type Value Definition/Defined In 
Reserved 0 
GSAKMP_ASN.1_PT_V1 1 All implementations of GSAKMP 


MUST support this PT format. 
Format specified in [RFC4534]. 


Reserved to IANA 2 - 49152 
Private Use 49153 - 65535 
Policy Token Data (variable length) - Contains Policy Token 


information. The values for this field are token specific, and 
the format is specified by the PT Type field. 


If this payload is encrypted, only the Policy Token Data field is 
encrypted. 


The payload type for the Policy Token Payload is one (1). 
7.3.2. Policy Token Payload Processing 


When processing the Policy Token Payload, the following fields MUST 
be checked for correct values: 


1. Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


2. Policy Token Type - The Policy Token Type value MUST be checked 
to be a valid policy token type as defined by Table 14. If the 
value is not valid, then an error is logged. If in Verbose Mode, 
an appropriate message containing notification value Payload- 
Malformed will be sent. 
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3. Policy Token Data - This Policy Token Data MUST be processed 
according to the Policy Token Type specified. The type will 
define the format of the data. 


7.4. Key Download Payload 


Refer to the terminology section for the different terms relating to 
keys used within this section. 


7.4.1. Key Download Payload Structure 


The Key Download Payload contains group keys (e.g., group keys, 
initial rekey keys, etc.). These key download payloads can have 
several security attributes applied to them based upon the security 
policy of the group. Figure 10 shows the format of the payload. 


The security policy of the group dictates that the key download 
payload MUST be encrypted with a key encryption key (KEK). The 
encryption mechanism used is specified in the Policy Token. The 
group members MUST create the KEK using the key creation method 
identified in the Key Creation Payload. 


0 1 2 3 
012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Number of Items ! Key Download Data Items f 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 10: Key Download Payload Format 

The Key Download Payload fields are defined as follows: 

Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 

RESERVED (1 octet) - Unused, set to 0. 

Payload Length (2 octets) - Length in octets of the current payload, 


including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 
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Number of Items (2 octets) - Contains the total number of group 
traffic protection keys and Rekey Arrays being passed in this 
data block. This field is treated as an unsigned integer in 
network byte order format. 


Key Download Data Items (variable length) - Contains Key Download 
information. The Key Download Data is a sequence of 
Type/Length/Data of the Number of Items. The format for each 
item is defined in Figure 11. 


0 1 2 3 
OAL. 2 3! 4:56 B90 1.:2,3 456178 9.0.1.2.34- 500 F-89201 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
KDD Item Type ! Key Download Data Item Length! K 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Data for Key Download Data Item (Key Datum/Rekey Array) m" 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


+ 


c+ 


+ 


Figure 11: Key Download Data Item Format 
For each Key Download Data Item, the data format is as follows: 


Key Download Data (KDD) Item Type (1 octet) - Identifier for the 
type of data contained in this Key Download Data Item. See 
Table 15 for the possible values of this field. This field 
is treated as an unsigned value. 


Key Download Data Item Length (2 octets) - Length in octets of 
the Data for the Key Download Data Item following this field. 
This field is treated as an unsigned integer in network byte 
order format. 


Data for Key Download Data Item (variable length) - Contains Keys 
and related information. The format of this field is 
specific depending on the value of the Key Download Data Item 
Type field. For KDD Item Type of GTPK, this field will 
contain a Key Datum as defined in Section 7.4.1.1. For KDD 
Item Type Rekey - LKH, this field will contain a Rekey Array 
as defined in Section 7.4.1.2. 
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Table 15: Key Download Data Item Types 


Key Download Data Value Definition 
Item Type 
GTPK 0 This type MUST be implemented. 


This type identifies that the 
data contains group traffic 
protection key information. 


Rekey - LKH 1 Optional 
Reserved to IANA 2 - 192 
Private Use 193 ="255 


The encryption of this payload only covers the data subsequent to the 
Generic Payload header (Number of Items and Key Download Data Items 
fields). 


The payload type for the Key Download Packet is two (2). 
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A Key Datum contains all the information for a key. 


GSAKMP 


Key Datum Structure 


the format for this structure. 


0 


1 2 


June 2006 


Figure 12 shows 


3 


01234567890123456789012345678090 m1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Key Type a 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Š ! Key Creation Date 


! Key ID 


! Key Handle 


+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4-4-4-4-4+-4+-4+-4-4-4-4-4-4-4-4-4 


+-4+-4-4-4-4-4-4-4-4-4+-4-4-4-4+-4+-4+-4+-4-4-4-4+-4+-4-4+-4+-4-4-4-4-4-4-4 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Key Expiration Date 


HA A A A A A A A A A A A A A A A A A A dd A o ++ 


+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4-4-4-4+-4-4-4-4-4-4-4-4-4-4 


+-4-4-4-4-4-4-4-4-4-4-4-4+-4-4-4+-4-4-4+-4+-4-4+-4+-4+-4-4-4-4-4-4-4-4-4 


Key Data 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Key T 


ype (2 octets) 
this key data is to be used. 


Figure 12: Key Datum Format 


Policy Token. 
field. 


Harney, 


et al. 


- This is the cryptographic algorithm for which 
This value is specified in the 


See Table 16 for the possible values of this 
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This field is treated as an unsigned value. 
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Table 16: Cryptographic Key Types 


Cryptographic_Key_Types Value Description/Defined In 

Reserved 0-2 

3DES_CBC64_192 3 See [RFC2451]. 

Reserved ee L 

AES_CBC_128 12 This type MUST be 
supported. See [IKEv2]. 

AES_CTR 13 See [IKEv2]. 

Reserved to IANA 14 - 49152 

Private Use 49153 - 65535 

Key ID (4 octets) - This is the permanent ID of all versions of the 


key. This value MAY be defined by the Policy Token. This field 
is treated as an octet string. 


Key Handle (4 octets) - This is the value to uniquely identify a 
version (particular instance) of a key. This field is treated as 
an octet string. 


Key Creation Date (15 octets) - This is the time value of when this 
key data was originally generated. This field contains the 
timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year 
(0000 — 9999), MM is the numerical value of the month (01 - 12), 
DD is the day of the month (01 - 31), HH is the hour of the day 
(00 — 23), MM is the minute within the hour (00 - 59), SS is the 
seconds within the minute (00 - 59), and the letter Z indicates 
that this is Zulu time. This format is loosely based on 
[RFC3161]. 


Key Expiration Date (15 octets) - This is the time value of when this 
key is no longer valid for use. This field contains the 
timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year 
(0000 — 9999), MM is the numerical value of the month (01 - 12), 
DD is the day of the month (01 - 31), HH is the hour of the day 
(00 — 23), MM is the minute within the hour (00 - 59), SS is the 


seconds within the minute (00 - 59), and the letter Z indicates 
that this is Zulu time. This format is loosely based on 
[RFC3161]. 

Key Data (variable length) - This is the actual key data, which is 


dependent on the Key Type algorithm for its format. 
NOTE: The combination of the Key ID and the Key Handle MUST be unique 


within the group. This combination will be used to uniquely identify 
a key. 
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7.4.1.2. Rekey Array Structure 


A Rekey Array contains the information for the set of KEKs that is 
associated with a Group Member. Figure 13 shows the format for this 
structure. 


0 1 2 3 
001.2:3:4 7506 890 1.2034 05 6: 1-8: 9-00 Te 228. 4 25.6 7. -8:.90: 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Rekey Version#! Member ID > 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Number of KEK Keys ! 7 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Key Datum(s) K 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


t+ i+ 


+ 


Figure 13: Rekey Array Structure Format 


Rekey Version (1 octet) - Contains the version of the Rekey protocol 
in which the data is formatted. For Key Download Data Item Type 
of Rekey - LKH, refer to Section A.2 for a description of this 
value. This field is treated as an unsigned value. 


Member ID (4 octets) - This is the Member ID of the Rekey sequence 
contained in this Rekey Array. This field is treated as an octet 
string. For Key Download Data Item Type of Rekey - LKH, refer to 
Section A.2 for a description of this value. 


Number of KEK Keys (2 octets) - This value is the number of distinct 
KEK keys in this sequence. This value is treated as an unsigned 
integer in network byte order format. 

Key Datum(s) (variable length) - The sequence of KEKs in Key Datum 
format. The format for each Key Datum in this sequence is 


defined in section 7.4.1.1. 


Key ID (for Key ID within the Rekey) - LKH space, refer to Section 
A.2 for a description of this value. 


7.4.2. Key Download Payload Processing 
Prior to processing its data, the payload contents MUST be decrypted. 


When processing the Key Download Payload, the following fields MUST 
be checked for correct values: 
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1. Next Payload, RESERVED, Payload Length - These fields are 


processed as defined in Section 7. 


Processing". 


2. KDD Item Type - All KDD Item Type 
valid Key Download Data Item type 


2.2, "Generic Payload Header 


fields MUST be checked to be a 


value is not valid, then an error 
an appropriate message containing 
Malformed will be sent. 


as defined by Table 15. If the 
is logged. If in Verbose Mode, 
notification value Payload- 


3. Key Type - All Key Type fields MUST be checked to be a valid 
encryption type as defined by Table 16. If the value is not 


valid, then an error is logged. 


If in Verbose Mode, an 


appropriate message containing notification value Invalid-Key- 


Information will be sent. 


4. Key Expiration Date - All Key Expiration Date fields MUST be 


checked confirm that their values 
past time value. If the value is 


represent a future and not a 
not valid, then an error is 


logged. If in Verbose Mode, an appropriate message containing 
notification value Invalid-Key-Information will be sent. 


The length and counter fields in the payload are used to help process 
the payload. If any field is found to be incorrect, then an error is 
logged. If in Verbose Mode, an appropriate message containing 
notification value Payload-Malformed will be sent. 


7.5. Rekey Event Payload 


Refer to the terminology section for the different terms relating to 


keys used within this section. 


7.5.1. Rekey Event Payload Structure 


The Rekey Event Payload MAY contain multiple keys encrypted in 
Wrapping KEKs. Figure 14 shows the format of the payload. If the 
data to be contained within a Rekey Event Payload is too large for 
the payload, the sequence can be split across multiple Rekey Event 
Payloads at a Rekey Event Data boundary. 
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0 Í 2 3 
0:01.2-314- 56. 7 8 9 01.2 ES 4 5:67 8 9 O12 3 4 SO). 8 9.0 1 
hd dd hd $ $ q — $ + q dd q + 4 q ++ +++ +++ +4 +++ 
Next Payload ! RESERVED ! Payload Length ! 
—t-+-t-4+-4+-4+-4+-4-4+-4+-4+-4-4+-4t-4-4-t-4+-4-t-4+-t-t-4-t-4-4-t-4-4t-t-4+ 
RekeyEvnt Type! Rekey Event Header 
hd dd hd $ $ q — $ + q + + $ + 4 + ++ +++ +++ +4 +++ 
Rekey Event Data (s) 
hd Hd hd de + de $ + q + d+ $ + 4 q ++ +++ +++ +4 +++ 


t+ +-+ 


+ 


Figure 14: Rekey Event Payload Format 
The Rekey Event Payload fields are defined as follows: 


Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 


Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 


Rekey Event Type (1 octet) - Specifies the type of Rekey Event being 
used. Table 17 presents the types of Rekey events. This field 
is treated as an unsigned value. 


Rekey Event Header (variable length) - This is the header information 
for the Rekey Event. The format for this is defined in Section 
7.5.1.1, "Rekey Event Header Structure". 

Rekey Event Data(s) (variable length) - This is the rekey information 
for the Rekey Event. The format for this is defined in Section 


7.5.1.2, "Rekey Event Data Structure". 


The Rekey Event payload type is three (3). 
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Value 


Rekey Event Types 


Definition/Defined In 


None 


GSAKMP_LKH 


Reserved to IANA 
Private Use 


2 
1:9 


=r: 
3) = 


92 
255 


This type MUST be implemented. 

In this case, the size of the Rekey 
Event Data field will be zero bytes 
long. The purpose of a Rekey Event 
Payload with type None is when it is 
necessary to send out a new token 
with no rekey information. GSAKMP 
rekey msg requires a Rekey Event 
Payload, and in this instance it 
would have rekey data of type None. 
The rekey data will be of 

type LKH formatted according to 
GSAKMP. The format for this field 
is defined in Section 7.5.1.2. 


7.5.1.1. Rekey Event Header Structure 


The format for the Rekey Event Header is shown in Figure 15. 


0 


I 


2 3 


Ope 2.3449 S A BZ A E E IO AZ A 076: SF 89 0001 


+-+-+-+-+-+-+-+-+- 


+-+-+-+-+-+-+-+-+- 


+-+-+-+-+-+-+-+-+- 
! Time/Date Stamp 


+-+-+-+-+-+-+-+- 


+-+-+-+-+-+-+-+- 


+-+-+-+-+-+-+-+- 
! Algorithm Ver 
+-+-+-+-+-+-+-+- 


Figure 15: 
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a 
$ 
y 
pS 


! 
+ 


+ 


+ 


+ 


+ = 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+ 


-+ 


-+ 


-+ 


-+ 


Group ID 
-+-+-+-+-+— 
Group ID 


-+-+ 


-+-+ 


-+-+ 


-+-+ 


-+-+ 


-+-+-+ 


-+-+-+ 


-+-+-+ 


-+-+-+ 


-+-+-+ 


Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value l 
—+-4+-4-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4-4-4+-4+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


! RekeyEnt Type 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! 


of Rekey Event Data(s) 
—t-+-4+-4+-4+-4+-+4+-4+-4+-4+-4-4-4-4-4+ 


Rekey Event Header Format 
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Group Identification Value (variable length) - Indicates the 
name/title of the group to be rekeyed. This is the same format, 
length, and value as the Group Identification Value in Section 
7.1, "GSAKMP Header". 


Time/Date Stamp (15 octets) - This is the time value when the Rekey 
Event Data was generated. This field contains the timestamp in 
UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 — 
9999), MM is the numerical value of the month (01 - 12), DD is 
the day of the month (01 - 31), HH is the hour of the day (00 - 
23), MM is the minute within the hour (00 - 59), SS is the 
seconds within the minute (00 - 59), and the letter Z indicates 
that this is Zulu time. This format is loosely based on 
[RFC3161]. 


Rekey Event Type (1 octet) - This is the Rekey algorithm being used 
for this group. The values for this field can be found in Table 
17. This field is treated as an unsigned value. 


Algorithm Version (1 octet) - Indicates the version of the Rekey Type 
being used. For Rekey Event Type of GSAKMP_LKH, refer to Section 
A.2 for a description of this value. This field is treated as an 
unsigned value. 


# of Rekey Event Data(s) (2 octets) - The number of Rekey Event 
Data(s) contained in the Rekey Data. This value is treated as an 
unsigned integer in network byte order. 


7.5.1.2. Rekey Event Data Structure 


As defined in the Rekey Event Header, # of Rekey Data(s) field, 
multiple pieces of information are sent in a Rekey Event Data. Each 
end user, will be interested in only one Rekey Event Data among all 
of the information sent. Each Rekey Event Data will contain all the 
Key Packages that a user requires. For each Rekey Event Data, the 
data following the Wrapping fields is encrypted with the key 
identified in the Wrapping Header. Figure 16 shows the format of 
each Rekey Event Data. 
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0 1 2 3 
001.23 45678901. 2345678901:2 3.4.5 67 8 9.0 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Packet Length ! Wrapping KeyID s 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +H 
! Wrapping Key Handle x 
—t-+-t-4+-4-4+-4+-4-4+-4+-4F-4t-4+-t-4-4-t-4+-4-t-4-t-t-4-t-4-4t-ta4-4t-t-4+ 
! # of Key Packages ! 


+ 


t 


A 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Key Packages (s) % 
+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


tk 
+ 
| 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 


Í 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 


Figure 16: Rekey Event Data Format 


Packet Length (2 octets) - Length in octets of the Rekey Event Data, 
which consists of the # of Key Packages and the Key Packages (s). 
This value is treated as an unsigned integer in network byte 
order. 


Wrapping KeyID (4 octets) - This is the Key ID of the KEK that is 
being used for encryption/decryption of the new (rekeyed) keys. 
For Rekey Event Type of Rekey - LKH, refer to Section A.2 for a 
description of this value. 


Wrapping Key Handle (4 octets) - This is a Key Handle of the KEK that 
is being used for encryption/decryption of the new (rekeyed) 
keys. Refer to Section 7.4.1.1 for the values of this field. 


# of Key Packages (2 octets) - The number of key packages contained 
in this Rekey Event Data. This value is treated as an unsigned 
integer in network byte order. 


Key Package(s) (variable length) - The type/length/value format of a 
Key Datum. The format for this is defined in Section 7.5.1.2.1. 


7.5.1.2.1. Key Package Structure 


Each Key Package contains all the information about the key. Figure 
17 shows the format for a Key Package. 


0 1 2 3 
OL E AO OO LS A 6 8 9 OA SA 400.06 Bis 9:00: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! KeyPkg Type ! Key Package Length ! Key Datum ad 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 17: Key Package Format 
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Key 


Key 


Key 


AS 


Package Type (1 octet) - The type of key in this key package. 
Legal values for this field are defined in Table 15, Key Download 
Data Types. This field is treated as an unsigned value. 


Package Length (2 octets) - The length of the Key Datum. This 
field is treated as an unsigned integer in network byte order 
format. 


Datum (variable length) - The actual data of the key. The format 
for this field is defined in Section 7.4.1.1, "Key Datum 


Structure". 


Rekey Event Payload Processing 


When processing the Rekey Event Payload, the following fields MUST be 
checked for correct values: 


Harney, 


Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


Rekey Event Type field within "Rekey Event" payload header - The 
Rekey Event Type MUST be checked to be a valid rekey event type 
as defined by Table 17. If the Rekey Event Type is not valid, 
then regardless of mode (e.g., Terse or Verbose) an error is 
logged. No response error message is generated for receipt of a 
Group Management Message. 


Group ID Value - The Group ID value of the Rekey Event Header 
received message MUST be checked against the GroupID of the Group 
Component. If no match is found, the payload is discarded, then 
regardless of mode (e.g., Terse or Verbose) an error is logged. 
No response error message is generated for receipt of a Group 
Management Message. 


Date/Time Stamp - The Date/Time Stamp value of the Rekey Event 
Header MAY be checked to determine if the Rekey Event generation 
time is recent relative to network delay and processing times. 
If the TimeStamp is judged not to be recent, an error is logged. 
No response error message is generated for receipt of a Group 
Management Message. 


Rekey Event Type field within the "Rekey Event Header" - The 
Rekey Event Type of the Rekey Event Header received message MUST 
be checked to be a valid rekey event type, as defined by Table 
17, and the same value of the Rekey Event Type earlier in this 
payload. If the Rekey Event Type is not valid or not equal to 
the previous value of the Rekey Event Type, then regardless of 
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The 


mode (e.g., Terse or Verbose) an error is logged. No response 
error message is generated for receipt of a Group Management 
Message. 


Algorithm Version - The Rekey Algorithm Version number MUST be 
checked to ensure that the version indicated is supported. If it 
is not supported, then regardless of mode (e.g., Terse or 
Verbose) an error is logged. No response error message is 
generated for receipt of a Group Management Message. 


length and counter fields are used to help process the message. 


If any field is found to be incorrect, then termination processing 
MUST be initiated. 


A GM MUST process all the Rekey Event Datas as based on the rekey 
method used there is a potential that multiple Rekey Event Datas are 


for 


this GM. The Rekey Event Datas are processed in order until all 


Rekey Event Datas are consumed. 


1. 


Wrapping KeyID - The Wrapping KeyID MUST be checked against the 
list of stored KEKs that this GM holds. If a match is found, 
then continue processing this Rekey Event Data. Otherwise, skip 
to the next Rekey Event Data. 


Wrapping Handle - If a matching Wrapping KeyID was found, then 
the Wrapping Handle MUST be checked against the handle of the KEK 
for which the KeyID was a match. If the handles match, then the 
GM will process the Key Packages associated with this Rekey Event 
Data. Otherwise, skip to the next Rekey Event Data. 


If a GM has found a matching Wrapping KeyID and Wrapping Handle, the 
GM decrypts the remaining data in this Rekey Event Data according to 
policy using the KEK defined by the Wrapping KeyID and Handle. After 
decrypting the data, the GM extracts the # of Key Packages field to 
help process the subsequent Key Packages. The Key Packages are 
processed as follows: 


L; 
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Key Package Type - The Key Package Type MUST be checked to be a 
valid key package type as defined by Table 15. If the Key 
Package Type is not valid, then regardless of mode (e.g., Terse 
or Verbose) an error is logged. No response error message is 
generated for receipt of a Group Management Message. 


Key Package Length - The Key Package Length is used to process 
the subsequent Key Datum information. 
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3. Key Type - The Key Type MUST be checked to be a valid key type as 
defined by Table 16. If the Key Package Type is not valid, then 
regardless of mode (e.g., Terse or Verbose) an error is logged. 
No response error message is generated for receipt of a Group 
Management Message. 


4. Key ID - The Key ID MUST be checked against the set of Key IDs 
that this user maintains for this Key Type. If no match is 
found, then regardless of mode (e.g., Terse or Verbose) an error 
is logged. No response error message is generated for receipt of 
a Group Management Message. 


5. Key Handle - The Key Handle is extracted as is and is used to be 
the new Key Handle for the Key currently associated with the Key 
Package's Key ID. 


6. Key Creation Date - The Key Creation Date MUST be checked that it 
is subsequent to the Key Creation Date for the currently held 
key. If this date is prior to the currently held key, then 
regardless of mode (e.g., Terse or Verbose) an error is logged. 
No response error message is generated for receipt of a Group 
Management Message. 


7. Key Expiration Date - The Key Expiration Date MUST be checked 
that it is subsequent to the Key Creation Date just received and 
that the time rules conform with policy. If the expiration date 
is not subsequent to the creation date or does not conform with 
policy, then regardless of mode (e.g., Terse or Verbose) an error 
is logged. No response error message is generated for receipt of 
a Group Management Message. 


8. Key Data - The Key Data is extracted based on the length 
information in the key package. 


If there were no errors when processing the Key Package, the key 
represented by the KeyID will have all of its data updated based upon 
the received information. 


7.6. Identification Payload 

7.6.1. Identification Payload Structure 
The Identification Payload contains entity-specific data used to 
exchange identification information. This information is used to 


verify the identities of members. Figure 18 shows the format of the 
Identification Payload. 
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! Next Payload 
+-+-+-+-+-+-+-+- 
! ID Classif 
+-+-+-+-+-+-+-+- 


Figure 18: 
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-+-+-+-+-+-+-+- 
RESERVED 
ed dd o o 

ID Type 
id od od o 


Identificat 


+ 
! 


+ 
! 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Payload Length ! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Identification Data a 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


ion Payload Format 


The Identification Payload fields are defined as follows: 


Next Payload 


the message, 


(1 octet) 
payload in the message. 
then this field will be 0. 
"chaining" capability. 


- Identif 
If 


Tabl 


ier for the payload type of the next 
the current payload is the last in 
This field provides the 
e 12 identifies the payload types. 


This field is treated as an unsigned value. 


RESERVED 


Payload Length 


(1 octet) 


(2 octets) 
including the generic payload header. 


— Unused, set 


- Leng 


to 0. 


th in octets of the current payload, 
This field is treated as 


an unsigned integer in network byte order format. 


Identification 


(ID) 
ownership of the Identification Data. 
possible values for this field. 


Classificati 


unsigned value. 


Identification 


(ID) 


(1 octet) - Classifies the 
Table 18 identifies 
This field is treated as an 


on 


Identification being used. 


for this type. 


This field i 


Table 18: Identification Classification 

ID_Classification Value 

Sender 0 

Receiver T 

Third Party 2 

Reserved to IANA 3 - 192 

Private Use 193 = 255 
Type (1 octet) - Specifies the type of 


Table 19 identifies possible values 
s treated as an unsigned value. All 


defined types are OPTIONAL unless otherwise stated. 
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Identification Data (variable length) - Contains identity 
information. The values for this field are group specific, and 
the format is specified by the ID Type field. The format for 
this field is stated in conjunction with the type in Table 19. 


The payload type for the Identification Payload is four (4). 


Table 19: Identification Types 


ID_Type Value PKIX Cert Description 
Field Defined In 

Reserved 0 

ID_IPV4_ADDR 1 SubjAltName See [IKEv2] 
iPAddress Section 3.5. 

ID_FODN 2 SubjAltName See [IKEv2] 
ANSName Section 3.5. 

ID_RFC822_ADDR 3 SubjAltName See [IKEv2] 
rfc822Name Section 3.5. 

Reserved 4 

ID_IPV6_ADDR 5 SubjAltName See [IKEv2] 
iPAddress Section 3.5. 

Reserved 6 - 8 

ID_DER_ASN1_DN 9 Entire Subject, See [IKEv2] 
bitwise Compare Section 3.5. 

Reserved 10 

ID_KEY_ID 11 N/A See [IKEv2] 

Reserved 12 - 29 Section 3.5. 

Unencoded Name 30 Subject The format for 

(ID_U_NAME) this type is 


defined in 
Section 7.6.1.1. 
ID_DN_STRING 31 Subject See [RFC4514]. 
This type MUST 
be implemented. 
Reserved to IANA 32. = 192 
Private Use 193 = 255 
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7.6.1.1. ID_U_NAME Structure 
The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19. 


0 1 2 3 
01234567890123456789012345678090m1 
—+-+4+-4+-4+-+-4+-4+-4+-+4+-4+-4+-4+-4-4+-4-+4+-4+-4+-4+-4-4+-4-+4+-4+-4+-+4+-4-4+-4-4+-4-4+ 
Serial Number = 
—+-+4+-4+-4+-+4+-4-4+-+-+-4+-4+-+4+-4-4+-4-+4+-4+-4+-+4-4-4+-4-4+-4+-4+-4+-4-4+-4+-4+-4-4+ 


+ 


t+ 


t + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


t + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


t + 


A A A A A A A A A A A A A A A A A A A dd + +4 

! 
A A A A A A A A A A A A A A A A A A dd A dd q ++ 
Length ! 
E 
DN Data j 
E 


-= + -- + 


+ 


Figure 19: Unencoded Name (ID-U-NAME) Format 


Serial Number (20 octets) - The certificate serial number. This 
field is treated as an unsigned integer in network byte order 
format. 

Length (4 octets) - Length in octets of the DN Data field. This 
field is treated as an unsigned integer in network byte order 
format. 

DN Data (variable length) - The actual UTF-8 DN value (Subject field) 


using the slash (/) character for field delimiters (e.g., 
"/C=US/ST=MD/L=Somewhere/O=ACME, Inc. /OU=DIV1/CN=user1/ 
Email=userl@acme.com" without the surrounding quotes). 


7.6.2. Identification Payload Processing 


When processing the Identification Payload, the following fields MUST 
be checked for correct values: 


1. Next Payload, RESERVED, Payload Length - These fields are 


processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


Harney, et al. Standards Track [Page 74] 


RFC 4535 GSAKMP June 2006 


2. Identification Classification - The Identification Classification 
value MUST be checked to be a valid identification classification 
type as defined by Table 18. If the value is not valid, then an 
error is logged. If in Verbose Mode, an appropriate message 
containing notification value Payload-Malformed will be sent. 


3. Identification Type - The Identification Type value MUST be 
checked to be a valid identification type as defined by Table 19. 
If the value is not valid, then an error is logged. If in 
Verbose Mode, an appropriate message containing notification 
value Payload-Malformed will be sent. 


4. Identification Data - This Identification Data MUST be processed 
according to the identification type specified. The type will 
define the format of the data. If the identification data is 
being used to find a match and no match is found, then an error 
is logged. If in Verbose Mode, an appropriate message containing 
notification value Invalid-ID-Information will be sent. 


7.6.2.1. ID_U_NAME Processing 


When processing the Identification Data of type ID_U_NAME, the 
following fields MUST be checked for correct values: 


1. Serial Number - The serial number MUST be a greater than or equal 
to one (1) to be a valid serial number from a conforming CA 
[RFC3280]. If the value is not valid, then an error is logged. 


If in Verbose Mode, an appropriate message containing 
notification value Payload-Malformed will be sent. 


2. DN Data - The DN data is processed as a UTF-8 string. 


3. The CA MUST be a valid trusted policy creation authority as 
defined by the Policy Token. 


These 2 pieces of information, Serial Number and DN Data, in 
conjunction, will then be used for party identification. These 
values are also used to help identify the certificate when necessary. 


7.7. Certificate Payload 

7.7.1. Certificate Payload Structure 
The Certificate Payload provides a means to transport certificates or 
other certificate-related information via GSAKMP and can appear in 
any GSAKMP message. Certificate payloads SHOULD be included in an 


exchange whenever an appropriate directory service (e.g., LDAP 
[RFC4523]) is not available to distribute certificates. Multiple 
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certificate payloads MAY be sent to enable verification of 
certificate chains. Conversely, zero (0) certificate payloads may be 
sent, and the receiving GSAKMP MUST rely on some other mechanism to 
retrieve certificates for verification purposes. Figure 20 shows the 
format of the Certificate Payload. 


0 1 2 3 
OL 2:3: 49 36 8-90 1.2 03409 6. 1-8::9:-0 1: 2:34:06 1.8.9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Cert Type ! Certificate Data i 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 20: Certificate Payload Format 
The Certificate Payload fields are defined as follows: 


Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 


Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 


Certificate Type (2 octets) - This field indicates the type of 
certificate or certificate-related information contained in the 
Certificate Data field. Table 20 presents the types of 
certificate payloads. This field is treated as an unsigned 
integer in network byte order format. 


Certificate Data (variable length) - Actual encoding of certificate 
data. The type of certificate is indicated by the Certificate 
Type/Encoding field. 


The payload type for the Certificate Payload is six (6). 
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7. 


7 


Table 20: Certificate Payload Types 


Certificate_Type Value Description/ 
Defined In 


None 0 

Reserved TVS 

X.509v3 Certificate 4 This type MUST be 
=- Signature implemented. 

-- DER Encoding Contains a DER 
encoded X.509 
certificate. 

Reserved NS) 
Certificate Revocation List 7 Contains a BER 

(CRL) encoded X.509 CRL. 

Reserved 8 - 9 

X.509 Certificate 10 See [IKEv2], Sec 3. 
-—- Attribute 

Raw RSA Key qi See [IKEv2], Sec 3. 

Hash and URL of X.509 12 See [IKEv2], Sec 3. 

Certificate 

Hash and URL of X.509 13 See [IKEv2], Sec 3. 

bundle 

Reserved to IANA 14 -- 49152 

Private Use 49153 == 65535 

-2. Certificate Payload Processing 


When processing the Certificate Payload, the following fields MUST 
checked for correct values: 


1. Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


Oo 


be 


2. Certificate Type - The Certificate Type value MUST be checked to 
be a valid certificate type as defined by Table 20. If the value 


is not valid, then an error is logged. If in Verbose Mode, an 
appropriate message containing notification value Cert-Type- 
Unsupported will be sent. 


3. Certificate Data - This Certificate Data MUST be processed 
according to the certificate type specified. The type will 


define the format of the data. Receipt of a certificate of the 


trusted policy creation authority in a Certificate payload causes 
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the payload to be discarded. This received certificate MUST NOT 
be used to verify the message. The certificate of the trusted 
policy creation authority MUST be retrieved by other means. 


7.8. Signature Payload 
7.8.1. Signature Payload Structure 


The Signature Payload contains data generated by the digital 
signature function. The digital signature, as defined by the 
dissection of each message, covers the message from the GSAKMP 
Message Header through the Signature Payload, up to but not 
including the Signature Data Length. Figure 21 shows the format 
of the Signature Payload. 


0 1 2 3 
Od 2-3 4506 T 28 901 2342 56:18 09-00-2034: 06: 7 8-90 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Next Payload ! RESERVED ! Payload Length ! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Signature Type ! Sig ID Type ! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Signature Timestamp 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


t+- +H 


c+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


c+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Signer ID Length ! 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Signer ID Data 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Signature Length ! Signature Data 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


eric RIA E 
+ 
l 


Í 
+ 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 21: Signature Payload Format 

The Signature Payload fields are defined as follows: 

Next Payload (1 octet) - Identifier for the payload type of the next 

payload in the message. If the current payload is the last in 

the message, then this field will be 0. This field provides the 

"chaining" capability. Table 12 identifies the payload types. 


This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 
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Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 


Signature Type (2 octets) - Indicates the type of signature. Table 
21 presents the allowable signature types. This field is treated 
as an unsigned integer in network byte order format. 


Table 21: Signature Types 


Signature Type Value Description/ 
Defined In 


DSS/SHA1 with ASN.1/DER encoding 0 This type MUST 
(DSS-SHA1-ASN1-DER) be supported. 
RSA1024-MD5 1 See [RFC3447]. 
ECDSA-P384-SHA3 2 See [FIPS186-2]. 
Reserved to IANA 3 - 41952 

Private Use 41953 - 65536 

Signature ID Type (1 octet) - Indicates the format for the Signature 


ID Data. These values are the same as those defined for the 
Identification Payload Identification types, which can be found 
in Table 19. This field is treated as an unsigned value. 


Signature Timestamp (15 octets) - This is the time value when the 
digital signature was applied. This field contains the timestamp 
in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 
9999), MM is the numerical value of the month (01 - 12), DD is 
the day of the month (01 - 31), HH is the hour of the day (00 - 
23), MM is the minute within the hour (00 - 59), SS is the 


seconds within the minute (00 - 59), and the letter Z indicates 
that this is Zulu time. This format is loosely based on 
[RFC3161]. 

Signer ID Length (2 octets) - Length in octets of the Signer’s ID. 


This field is treated as an unsigned integer in network byte 
order format. 


Signer ID Data (variable length) - Data identifying the Signer’s ID 
(e.g., DN). The format for this field is based on the Signature 
ID Type field and is shown where that type is defined. The 
contents of this field MUST be checked against the Policy Token 
to determine the authority and access of the Signer within the 
context of the group. 
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Signature Length (2 octets) - Length in octets of the Signature Data. 


This field is treated as an unsigned integer in network byte 
order format. 


Signature Data (variable length) - Data that results from applying 


The 


LS Lv 


the digital signature function to the GSAKMP message and/or 
payload. 


payload type for the Signature Payload is eight (8). 


Signature Payload Processing 


When processing the Signature Payload, the following fields MUST be 
checked for correct values: 


Harney, 


Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


Signature Type - The Signature Type value MUST be checked to be a 
valid signature type as defined by Table 21. If the value is not 
valid, then an error is logged. If in Verbose Mode, an 
appropriate message containing notification value Payload- 
Malformed will be sent. 


Signature ID Type - The Signature ID Type value MUST be checked 
to be a valid signature ID type as defined by Table 19. If the 
value is not valid, then an error is logged. If in Verbose Mode, 
an appropriate message containing notification value Payload- 
Malformed will be sent. 


Signature Timestamp - This field MAY be checked to determine if 
the transaction signing time is fresh relative to expected 
network delays. Such a check is appropriate for systems in which 
archived sequences of events are desired. 


NOTE: The maximum acceptable age of a signature timestamp 
relative to the local system clock is a locally configured 
parameter that can be tuned by its GSAKMP management interface. 


Signature ID Data - This field will be used to identify the 
sending party. This information MUST then be used to confirm 
that the correct party sent this information. This field is also 
used to retrieve the appropriate public key of the certificate to 
verify the message. 
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6. Signature Data - This value MUST be compared to the recomputed 
signature to verify the message. Information on how to verify 
certificates used to ascertain the validity of the signature can 
be found in [RFC3280]. Only after the certificate identified by 
the Signature ID Data is verified can the signature be computed 
to compare to the signature data for signature verification. A 
potential error that can occur during signature verification is 
Authentication-Failed. Potential errors that can occur while 
processing certificates for signature verification are: Invalid- 
Certificate, Invalid-Cert-Authority, Cert-Type-Unsupported, and 
Certificate-Unavailable. 


The length fields in the Signature Payload are used to process the 
remainder of the payload. If any field is found to be incorrect, 
then termination processing MUST be initiated. 


7.9. Notification Payload 
7.9.1. Notification Payload Structure 


The Notification Payload can contain both GSAKMP and group-specific 
data and is used to transmit informational data, such as error 
conditions, to a GSAKMP peer. It is possible to send multiple 
independent Notification payloads in a single GSAKMP message. Figure 
22 shows the format of the Notification Payload. 


0 1 2 3 
O123-45 673901234 56 7°38 9 01234567 89 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Notification Type ! Notification Data 7 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 22: Notification Payload Format 

The Notification Payload fields are defined as follows: 

Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"chaining" capability. Table 12 identifies the payload types. 


This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 
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Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 


Notification Type (2 octets) - Specifies the type of notification 
message. Table 22 presents the Notify Payload Types. This field 
is treated as an unsigned integer in network byte order format. 

Notification Data (variable length) - Informational or error data 
transmitted in addition to the Notify Payload Type. Values for 
this field are Domain of Interpretation (DOI) specific. 


The payload type for the Notification Payload is nine (9). 


Table 22: Notification Types 


Notification Type Value 
None 0 
Invalid-Payload-Type 1 
Reserved LES 
Invalid-Version 4 
Invalid-Group-ID 5 
Invalid-Sequence-ID 6 
Payload-Malformed 7 
Invalid-Key-Information 8 
Invalid-ID-Information 9 
Reserved 10: = 11 
Cert-Type-Unsupported 12 
Invalid-Cert-Authority 13 
Authentication-Failed 14 
Reserved 10-16 
Certificate-Unavailable L7 
Reserved 18 
Unauthorized-Request 19 
Reserved 20 - 22 
Acknowledgement 23 
Reserved 24 =25 
Nack 26 
Cookie-Required 27 
Cookie 28 
Mechanism Choices 29 
Leave Group 30 
Departure Accepted 3:1 
Request to Depart Error 32 
Invalid Exchange Type 33 
IPv4 Value 34 
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IPv6 Value 


Prohibited by Group Policy 


Prohibited by Lo 


Reserved to IANA 


Private Use 


did delos 
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35 
36 
cally Configured Policy 37 
38 - 49152 
49153: == 65535 
Notification Data - Acknowledgement (ACK) Payload Type 


The data portion of the Notification payload of type ACK either 


serves as confirmat 
or, 
a signed message. 

Data - Acknowledge 


0 
OM. 23+ 4a 9) 16 78 


ion of correct receipt of the Key Download message 


when needed, provides other receipt information when included in 


Figure 23 shows the format of the Notification 
Payload Type. 


1 2 3 
9:01:23 45:06 478 9 OL 2 3 A916 FB. 9. «Oi 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


! Ack Type ! 


Acknowledgement Data 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 23: 


Notification Data - Acknowledge Payload Type Format 


The Notification Data - Acknowledgement Payload Type data fields are 


defined as follows: 


Ack Type (1 octet) 


presents the Notify Acknowledgement Payload Types. 


- Specifies the type of acknowledgement. Table 23 
This field is 


treated as an unsigned value. 


Table 23: Acknowledgement Types 
ACK_Type Value Definition 
Simple 0 Data portion null. 
Reserved to IANA d+ 1:92 
Private Use 1:93: = -2959 


IAS EA 


Notification Data - Cookie_Required and Cookie Payload Type 


The data portion of the Notification payload of types Cookie_Required 


and Cookie contain 
have been computed 


The value for this field will 
The GM 


the Cookie value. 
by the responder GC/KS and sent to the GM. 


will take the value received and copy it into the Notification 
payload Notification Data field of type Cookie that is transmitted in 


the "Request to Join with Cookie Info" back to the GC/KS. 


The cookie 


value MUST NOT be modified. 
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The format for this is already described in the discussion on cookies 
in Section 5.2.2. 


7.9.1.3. Notification Data - Mechanism Choices Payload Type 


The data portion of the Notification payload of type Mechanism 
Choices contains the mechanisms the GM is requesting to use for the 
negotiation with the GC/KS. This information will be supplied by the 
GM in a RTJ message. Figure 24 shows the format of the Notification 
Data - Mechanism Choices Payload Type. Multiple type|length|data 
choices are strung together in one notification payload to allow a 
user to transmit all relevant information within one Notification 
Payload. The length of the payload will control the parsing of the 
Notification Data Mechanism Choices field. 


0 Í 2 3 
0:12 34006: T 28. 901 2.3.4.5 6 TP B89 Oe 23 4 6 7 8-90 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Mech Type ! Mechanism Choice Data ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.. 


Figure 24: Notification Data - Mechanism Choices Payload Type Format 


The Notification Data - Mechanism Choices Payload Type data fields 
are defined as follows: 


Mechanism Type (1 octet) - Specifies the type of mechanism. Table 24 
presents the Notify Mechanism Choices Mechanism Types. This 
field is treated as an unsigned value. 


Table 24: Mechanism Types 


Mechanism_Type Value Mechanism Choice 
Data Value Table Reference 


Key Creation Algorithm 0 Table 26 
Encryption Algorithm 1 Table 16 
Nonce Hash Algorithm 2 Table 25 
Reserved to IANA 3 = 1:92 
Private Use 193 -= 255 
Mechanism Choice Data (2 octets) - The data value for the mechanism 


type being selected. The values are specific to each Mechanism 
Type defined. All tables necessary to define the values that are 
not defined elsewhere (in this specification or others) are 
defined here. This field is treated as an unsigned integer in 
network byte order format. 
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Table 25: Nonce Hash Types 


Nonce_Hash_Type Value Description 

Reserved 0 

SHA-1 1 This type MUST be supported. 
Reserved to IANA 2 - 49152 

Private Use 49153 - 65535 


7.9.1.4. Notification Data - IPv4 and IPv6 Value Payload Types 


The data portion of the Notification payload of type IPv4 and IPv6 
value contains the appropriate IP value in network byte order. This 
value will be set by the creator of the message for consumption by 
the receiver of the message. 


7.9.2. Notification Payload Processing 


When processing the Notification Payload, the following fields MUST 
be checked for correct values: 


1. Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


2. Notification Type - The Notification type value MUST be checked 
to be a notification type as defined by Table 22. If the value 
is not valid, then an error is logged. If in Verbose Mode, an 
appropriate message containing notification value Payload- 
Malformed will be sent. 


3. Notification Data - This Notification Data MUST be processed 
according to the notification type specified. The type will 
define the format of the data. When processing this data, any 
type field MUST be checked against the appropriate table for 
correct values. If the contents of the Notification Data are not 
valid, then an error is logged. If in Verbose Mode, an 
appropriate message containing notification value Payload- 
Malformed will be sent. 
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7.10. Vendor ID Payload 
7.10.1. Vendor ID Payload Structure 


The Vendor ID Payload contains a vendor-defined constant. The 
constant is used by vendors to identify and recognize remote 
instances of their implementations. This mechanism allows a 
vendor to experiment with new features while maintaining 
backwards compatibility. Figure 25 shows the format of the 
payload. 


0 1 2 3 
0123.45 67 8 9 0 1-253 4°:5:678 9 O12 3 45 6:7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

! Next Payload ! RESERVED ! Payload Length 
a ii e aN a a a a ok ne 
! Vendor ID (VID) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 25: Vendor ID Payload Format 


A Vendor ID payload MAY announce that the sender is capable of 
accepting certain extensions to the protocol, or it MAY simply 
identify the implementation as an aid in debugging. A Vendor ID 
payload MUST NOT change the interpretation of any information defined 
in this specification. Multiple Vendor ID payloads MAY be sent. An 
implementation is NOT REQUIRED to send any Vendor ID payload at all. 


A Vendor ID payload may be sent as part of any message. Receipt of a 
familiar Vendor ID payload allows an implementation to make use of 
Private Use numbers described throughout this specification -- 
private payloads, private exchanges, private notifications, etc. 

This implies that all the processing rules defined for all the 
payloads are now modified to recognize all values defined by this 
Vendor ID for all fields of all payloads. Unfamiliar Vendor IDs MUST 
be ignored. 


Writers of Internet-Drafts who wish to extend this protocol MUST 
define a Vendor ID payload to announce the ability to implement the 
extension in the Internet-Draft. It is expected that Internet-Drafts 
that gain acceptance and are standardized will be given assigned 
values out of the Reserved to IANA range, and the requirement to use 
a Vendor ID payload will go away. 


The Vendor ID payload fields are defined as follows: 
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Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"Chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 


Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 


Vendor ID (variable length) - The Vendor ID value. The minimum 
length for this field is four (4) octets. It is the 
responsibility of the person choosing the Vendor ID to assure its 
uniqueness in spite of the absence of any central registry for 
IDs. Good practice is to include a company name, a person name, 
or Similar type data. A message digest of a long unique string 
is preferable to the long unique string itself. 


The payload type for the Vendor ID Payload is ten (10). 
7.10.2. Vendor ID Payload Processing 


When processing the Vendor ID Payload, the following fields MUST be 
checked for correct values: 


1. Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


2. Vendor ID - The Vendor ID Data MUST be processed to determine if 
the Vendor ID value is recognized by the implementation. If the 
Vendor ID value is not recognized, then regardless of mode (e.g., 
Terse or Verbose) this information is logged. Processing of the 
message MUST continue regardless of recognition of this value. 


It is recommended that implementations that want to use Vendor-ID- 
specific information attempt to process the Vendor ID payloads of an 
incoming message prior to the remainder of the message processing. 
This will allow the implementation to recognize that when processing 
other payloads it can use the larger set of values for payload fields 
(Private Use values, etc.) as defined by the recognized Vendor IDs. 
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7.11. Key Creation Payload 
7.11.1. Key Creation Payload Structure 


The Key Creation Payload contains information used to create key 
encryption keys. The security attributes for this payload are 
provided in the Policy Token. Figure 26 shows the format of the 
payload. 


0 1 2 3 
012345 67°39 012345 678 9012345678 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Key Creation Type ! Key Creation Data = 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 26: Key Creation Payload Format 
The Key Creation Payload fields are defined as follows: 


Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 


Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 


Key Creation Type (2 octets) - Specifies the type of Key Creation 
being used. Table 26 identifies the types of key creation 
information. This field is treated as an unsigned integer in 
network byte order format. 


Key Creation Data (variable length) - Contains Key Creation 
information. The values for this field are group specific, and 


the format is specified by the key creation type field. 


The payload type for the Key Creation Packet is eleven (11). 
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Table 26: Types of Key Creation Information 


Key Creation Type Value Definition/Defined In 
Reserved Oa 
Diffie-Hellman 2 This type MUST be supported. 
1024-bit MODP Group Defined in [IKEv2] B.2. 
Truncated If the output of the process 
is longer than needed for 
the defined mechanism, use 
the first X low order bits 
and truncate the remainder. 
Reserved e = 13 
Diffie-Hellman 14 Defined in [RFC3526]. 
2048-bit MODP Group If the output of the process 
Truncated is longer than needed for 
the defined mechanism, use 
the first X low order bits 
and truncate the remainder. 
Reserved to IANA 15 - 49152 
Private Use 49153 - 65535 
7.11.2. Key Creation Payload Processing 
The specifics of the Key Creation Payload are defined in Section 


Peo Lo, 


When processing the Key Creation Payload, the following fields MUST 
be checked for correct values: 


Harney, 


Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


Key Creation Type - The Key Creation Type value MUST be checked 
to be a valid key creation type as defined by Table 26. If the 
value is not valid, then an error is logged. If in Verbose Mode, 
an appropriate message containing notification value Payload- 
Malformed will be sent. 


Key Creation Data - This Key Creation Data MUST be processed 
according to the key creation type specified to generate the KEK 
to protect the information to be sent in the appropriate message. 
The type will define the format of the data. 
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Implementations that want to derive other keys from the initial Key 
Creation keying material (for example, DH Secret keying material) 
MUST define a Key Creation Type other than one of those shown in 
Table 26. The new Key Creation Type must specify that derivation’s 
algorithm, for which the KEK MAY be one of the keys derived. 


7.12. Nonce Payload 
7.12.1. Nonce Payload Structure 


The Nonce Payload contains random data used to guarantee freshness 
during an exchange and protect against replay attacks. Figure 27 
shows the format of the Nonce Payload. 


0 1 2 3 
01.2: 34-906 2-89 Or 2 B45 G 8 9. OL: 23-45 68 7-89 Oi 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Nonce Type ! Nonce Data y 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 27: Nonce Payload Format 
The Nonce Payload fields are defined as follows: 


Next Payload (1 octet) - Identifier for the payload type of the next 
payload in the message. If the current payload is the last in 
the message, then this field will be 0. This field provides the 
"chaining" capability. Table 12 identifies the payload types. 
This field is treated as an unsigned value. 


RESERVED (1 octet) - Unused, set to 0. 

Payload Length (2 octets) - Length in octets of the current payload, 
including the generic payload header. This field is treated as 
an unsigned integer in network byte order format. 

Nonce Type (1 octet) - Specifies the type of nonce being used. Table 


27 identifies the types of nonces. This field is treated as an 
unsigned value. 
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Table 27: Nonce Types 


Nonce_Type Value Definition 
None 0 

Initiator (Nonce_I) 1 

Responder (Nonce_R) 2 

Combined (Nonce_C) 3 Hash (Append 


(Initiator_Value, Responder_Value) ) 
The hash type comes from the 
Policy (e.g., Security Suite 
Definition of Policy Token). 


Reserved to IANA 4 - 192 
Private Use 1:92 =:200 
Nonce Data (variable length) - Contains the nonce information. The 


values for this field are group specific, and the format is 
specified by the Nonce Type field. If no group-specific 
information is provided, the minimum length for this field is 4 
bytes. 


The payload type for the Nonce Payload is twelve (12). 
7.12.2. Nonce Payload Processing 


When processing the Nonce Payload, the following fields MUST be 
checked for correct values: 


1. Next Payload, RESERVED, Payload Length - These fields are 
processed as defined in Section 7.2.2, "Generic Payload Header 
Processing". 


2. Nonce Type - The Nonce Type value MUST be checked to be a valid 
nonce type as defined by Table 27. If the value is not valid, 


then an error is logged. If in Verbose Mode, an appropriate 
message containing notification value Payload-Malformed will be 
sent. 


3. Nonce Data - This is the nonce data and it must be checked 
according to its content. The size of this field is defined in 
Section 7.12, "Nonce Payload". Refer to Section 5.2, "Group 
Establishment", for interpretation of this field. 
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8. GSAKMP State Diagram 


Figure 28 presents the states encountered in the use of this 
protocol. Table 28 defines the states. Table 29 defines the 


transitions. 

(=== RS ===2 5 > ( ) 
! Y === === === === > ( Idle ) LO O ! 
! ! ( ) ! 
! ! ! ! ! 
! ! ! ! ! 
! ! (la) (1) ! 
! ! ! ! ! 
! ! ! ! ! 
! ! V V ! 
! !---(5a)--- (Wait for ) (Wait for ) ----(5)----- ! 
! (Group ) (GC/KS Event) <--- 
! (Membership) Ae \ \ 
! ! ! ! \ \ 
! ! ! ! \--(2)---\ 
! (2a) (4) (3) 
! ! ! ! 
! ! ! ! 
! V ! Vv 
Leo (4a)--- (Wait for ) (Wait for ) 

(Group ) (Response ) 

(Membership) (from Key ) 

/--> (Event ) (Download ) 
/ / 
/ / 
/--(3a)---/ 


Figure 28: GSAKMP State Diagram 
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Table 28: GSAKMP States 


Idle : GSAKMP Application waiting for input 


Wait for GC/KS Event : GC/KS up and running, waiting for events 


Wait for Response : GC/KS has sent Key Download, 
from Key Download : waiting for response from GM 
Wait for Group : GM in process of joining group 

Membership 
Wait for Group : GM has group key, waiting for 
Membership Event : group management messages. 
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Table 29: State Transition Events 


Transition 1 : Create group command 


Transition 2 : Receive bad RTJ 
Receive valid command to change group membership 
Send Compromise message x times 
Member Deregistration 


Transition 3 : Receive valid RIJ 


Transition 4 : Timeout 
Receive Ack 
Receive Nack 


Transition 5 : Delete group command 
Transition la : Join group command 
Transition 2a : Send Ack 


Transition 3a : Receipt of group management messages 


Transition 4a : Delete group command 
Deregistration command 


Transition 5a : Time out 
Msg failure 
errors 
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9. IANA Considerations 
9.1. IANA Port Number Assignment 


IANA has provided GSAKMP port number 3761 in both the UDP and TCP 
spaces. All implementations MUST use this port assignment in the 
appropriate manner. 


9.2. Initial IANA Registry Contents 
The following registry entries have been created: 


GSAKMP Group Identification Types (Section 7.1.1) 
GSAKMP Payload Types (Section 7.1.1) 

GSAKMP Exchange Types (Section 7.1.1) 

GSAKMP Policy Token Types (Section 7.3.1) 

GSAKMP Key Download Data Item Types (Section 7.4.1) 
GSAKMP Cryptographic Key Types (Section 7.4.1.1) 
GSAKMP Rekey Event Types (Section 7.5.1) 

GSAKMP Identification Classification (Section 7.6.1) 
GSAKMP Identification Types (Section 7.6.1) 

GSAKMP Certificate Types (Section 7.7.1) 

GSAKMP Signature Types (Section 7.8.1) 

GSAKMP Notification Types (Section 7.9.1) 

GSAKMP Acknowledgement Types (Section 7.9.1.1) 
GSAKMP Mechanism Types (Section 7.9.1.3) 

GSAKMP Nonce Hash Types (Section 7.9.1.3) 

GSAKMP Key Creation Types (Section 7.11.1) 

GSAKMP Nonce Types (Section 7.12.1) 


Changes and additions to the following registries are by IETF 
Standards Action: 


GSAKMP Group Identification Types 
GSAKMP Payload Types 

GSAKMP Exchange Types 

GSAKMP Policy Token Types 

GSAKMP Key Download Data Item Types 
GSAKMP Rekey Event Types 

GSAKMP Identification Classification 
GSAKMP Notification Types 

GSAKMP Acknowledgement Types 

GSAKMP Mechanism Types 

GSAKMP Nonce Types 
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10. 


Changes and additions to the following registries are by Expert 
Review: 


GSAKMP Cryptographic Key Types 
GSAKMP Identification Types 
GSAKMP Certificate Types 
GSAKMP Signature Types 

GSAKMP Nonce Hash Types 

GSAKMP Key Creation Types 
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Appendix A. LKH Information 


A. 


iS 


This appendix will give an overview of LKH, define the values for 
fields within GSAKMP messages that are specific to LKH, and give an 
example of a Rekey Event Message using the LKH scheme. 


LKH Overview 


LKH provides a topology for handling key distribution for a group 
rekey. It rekeys a group based upon a tree structure and subgroup 
keys. In the LKH tree shown in Figure 29, members are represented by 
the leaf nodes on the tree, while intermediate tree nodes represent 
abstract key groups. A member will possess multiple keys: the group 
traffic protection key (GTPK), subgroup keys for every node on its 
path to the root of the tree, and a personal key. For example, the 
member labeled as #3 will have the GTPK, Key A, Key D, and Key 3. 


root 
/ \ 
/ \ 
A B 
/ \ / \ 
/ \ / \ 
C D E F 
/ \ / \ / \ / \ 
/ \ / \ / \ / \ 
i 2 3 4 5 6 7 8 


Figure 29: LKH Tree 


This keying topology provides for a rapid rekey to all but a 
compromised member of the group. If Member 3 were compromised, the 
new GTPK (GTPK’) would need to be distributed to the group under a 
key not possessed by Member 3. Additionally, new Keys A and D (Key 
A’ and Key D’) would also need to be securely distributed to the 
other members of those subtrees. Encrypting the GIPK’ with Key B 
would securely distribute that key to Members 5, 6, 7, and 8. Key C 
can be used to encrypt both the GTPK” and Key A’ for Members 1 and 2. 
Member 3’s nearest neighbor, Member 4, can obtain GTPK’, Key D’, and 
Key A’ encrypted under its personal key, Key 4. At the end of this 
process, the group is securely rekeyed with Member 3 fully excluded. 
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When using LKH with GSAKMP, 


1. 


For the following discussion, 
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LKH and GSAKMP 
the following issues require attention: 


Rekey Version $ - The Rekey Version # in the Rekey Array of the 
Key Download Payload MUST contain the value one (1). 


Algorithm Version - The Algorithm Version in the Rekey Event 
Payload MUST contain the value one (1). 

Degree of Tree - The LKH tree used can be of any degree; it need 
not be binary. 


Node Identification - Each node in the tree is treated as a KEK. 
A KEK is just a special key. As the rule stated for all keys in 
GSAKMP, the set of the KeyID and the KeyHandle MUST be unique. A 
suggestion on how to do this will be given in this section. 


Wrapping KeyID and Handle - This is the KeyID and Handle of the 
LKH node used to wrap/encrypt the data in a Rekey Event Data. 


refer to Figure 30. 


Key: 


o: 
N: 
L: 


Harney, 


a node in the LKH tree 
this line contains the KeyID node number 
this line contains the MemberID number for all leaves ONLY 


LEVEL 
root o) 
/ 1 \ 
/ \ 
1 o o) 
/ 2 \ Po Bo Xx 
/ \ / \ 
2 o o) o) o 
/4\ /5\ /6\ IM 
/ \ / \ / \ / \ 
3 o o o) o) o) o) o o) 
8 9 10 11 12 T3 14 15 
j; 2 3 4 5 6 7 8 
Figure 30: GSAKMP LKH Tree 
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KeyID, 
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the Rekey Controller SHOULD build a 
virtual tree and label the KeyID of each node, 


doing a breadth-first 


search of a fully populated tree regardless of whether or not the 


tree is actually full. 


For simplicity of this example, 
the tree was given KeyID value of one (1). 
be static throughout the life of this tree. 


the root of 
These KeyID values will 
Additionally, the rekey 


arrays distributed to GMs requires a MemberID value associated with 


them to be distributed with the KeyDownload Payload. 
the set associated with each leaf 
(the nodes from that leaf back to the root) 


values MUST be unique. 


Therefore, 


node 

MemberID. In this example, 
value of one (1). 

lines N) and the MemberIDs 


These MemberID 


are given a 


the leftmost leaf node is given MemberID 


These 2 sets of values, 
(represented on line L), 


the KeyIDs (represented on 
will give 


sufficient information in the KeyDownload and RekeyEvent Payloads to 


disseminate information. 


The KeyHandle associated with these keys is 


regenerated each time the key is replaced in the tree due to 


compromise. 
A.3. LKH Examples 


Definition of values: 


OxLLLL - length value 

OxHHHHHHH+ - handle value 

YYYYMMDDHHMMSSZ - time value 
A.3.1. LKH Key Download Example 


This section will give an example of the data for the Key Download 


payload. 


The GM will be given MemberID 1 and its associated keys. 


The data shown will be subsequent to the Generic Payload Header. 


| GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8 


Number of Items 
Item #1: 
Key Download Data Item 
Key Download Data Item 
Key Type 
Key ID 
Key Handle 
Key Creation Date 
Key Expiration Date 
Key Data 
Item #2: 
Key Download Data Item 
Key Download Data Item 
Rekey Version Number 
Member ID 
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Type 
Length 


Type 
Length 
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0x0002 


0x00 (GTPK) 

OxLLLL 

0x03 (3DES'CBC64'192) 

KEY1 

OxHHHHHHHO 

YY YYMMDDHHMMSSZ 

YY YYMMDDHHMMSSZ 

variable, based on key definition 


0x01 (Rekey - LKH) 
OxLLLL 

0x01 

0x00000001 


[Page 102] 


RFC 4535 GSAKMP June 2006 


A. 


3 


Number of KEK Keys - 0x0003 

KEK #1: 

Key Type — 0x03 (3DES'CBC64'192) 

Key ID - 0x00000002 

Key Handle — OxHHHHHHH2 

Key Creation Date — YYYYMMDDHHMMSSZ 

Key Expiration Date — YYYYMMDDHHMMSSZ 

Key Data - variable, based on key definition 
KEK #2: 

Key Type - 0x03 (3DES'CBC64'192) 

Key ID - 0x00000004 

Key Handle — OxHHHHHHH4 

Key Creation Date — YYYYMMDDHHMMSSZ 

Key Expiration Date — YYYYMMDDHHMMSSZ 

Key Data - variable, based on key definition 
KEK #3: 

Key Type — 0x03 (3DES'CBC64'192) 

Key ID - 0x00000008 

Key Handle — OxHHHHHHH8 

Key Creation Date — YYYYMMDDHHMMSSZ 

Key Expiration Date — YYYYMMDDHHMMSSZ 

Key Data - variable, based on key definition 


.2. LKH Rekey Event Example 


This section will give an example of the data for the Rekey Event 
payload. The GM with MemberID 6 will be keyed out of the group. The 
data shown will be subsequent to the Generic Payload Header. 


| Rekey Event Type | GroupID | Date/Time | Rekey Type | 
Algorithm Ver | # of Packets | 
{ (GTPK)2, (GTPK, 3’, 6’)12, (GTPK, 3’)7 } 


This data shows that three packets are being transmitted. Read each 
packet as: 


a) GIPK wrapped in LKH KeyID 2 
b) GTPK, LKH KeyIDs 3’ € 6’, all wrapped in LKH KeyID 12 
c) GTPK and LKH KeyID 3’, all wrapped in LKH KeyID 7 


NOTE: Although in this example multiple keys are encrypted under one 
key, alternative pairings are legal (e.g., (GTPK)2, (GTPK)3’, (3')6', 
(3')77, (67)12). 


We will show the format for all header data and packet (b). 
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Rekey Event Type - 0x01 (GSAKMP “*LKH) 
GroupID — OXAABBCCDD 
0x12345678 
Time/Date Stamp — YYYYMMDDHHMMSSZ 
Rekey Event Type - 0x01 (GSAKMP “*LKH) 
Algorithm Vers - 0x01 
# of RkyEvt Pkts - 0x0003 
For Packet (b): 
Packet Length - OxLLLL 
Wrapping KeyID - 0x000C 
Wrapping Key Handle - OxHHHHHHHD 
# of Key Packages - 0x0003 
Key Package 1: 
Key Pkg Type - 0x00 (GTPK) 
Pack Length - OxLLLL 
Key Type - 0x03 (3DES'CBC64'192) 
Key ID - KEY1 
Key Handle — OxHHHHHHHO 
Key Creation Date — YYYYMMDDHHMMSSZ 
Key Expiration Date - YYYYMMDDHHMMSSZ 
Key Data - variable, based on key definition 
Key Package 2: 
Key Pkg Type - 0x01 (Rekey - LKH) 
Pack Length — OxLLLL 
Key Type — 0x03 (3DES'CBC64'192) 
Key ID - 0x00000003 
Key Handle — OxHHHHHHH3 
Key Creation Date - YYYYMMDDHHMMSSZ 
Key Expiration Date - YYYYMMDDHHMMSSZ 
Key Data - variable, based on key definition 
Key Package 3: 
Key Pkg Type - 0x01 (Rekey - LKH) 
Pack Length — OxLLLL 
Key Type - 0x03 (3DES'CBC64'192) 
Key ID - 0x00000006 
Key Handle — OxHHHHHHH6 
Key Creation Date - YYYYMMDDHHMMSSZ 
Key Expiration Date - YYYYMMDDHHMMSSZ 
Key Data - variable, based on key definition 
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